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1.0  nramJcrrcN 


This  is  the  final  report  for  the  ^'Study  of  the  Use  of  Ada  in  Trusted  Computing 
Bases  (TCBs)  to  be  certified  at,  or  below,  the  B3  Level."  The  objective  of  the 
study  was  to  produce  guidelines  for  developing  Ada  software  for  TCBs.  This 
objective  was  addressed  in  a  three-part  process: 


1) 

2) 

3) 


Mapping  the  Trusted  Computer  System  Evaluation  Criteria  (TCSEC)  to  the 
software  development  process  ‘ 


Identifying  benefits  of  and  potential  deterrents  to  using  Ada  in  the 
software  development  process  of  TCB  systems  ' 


Producing  the  guidelines. 


C !^7 


c 


The  Trapping  of  the  TCSEC  to  the  software  development  process  was  done  to  identify 
precisely  where  and  hew  application  of  the  TCSEC  affected  the  software 
development  process.  This  task  is  described  in  Section  2.0.  The  mapping  is 
contained  in  Appendix  A. 


The  identification  of  benefits  of  and  potential  deterrents  to  using  Ada  in  TCBs 
was  based  on  knowing  where  and  hew  TCSEC  criteria  affected  software  development. 
These  benefits  and  deterrents  form  the  rationale  for  the  guidelines.  The 
rationale  is  described  in  Section  3.0,  and  the  listing  of  benefits  and  potential 
deterrents  is  in  Appendix  B. 


The  guidelines  produced  are  based  on  the  rationale.  The  use  of  the  guidelines  is 
discussed  in  Section  4.0,  and  the  guidelines  are  presented  in  Appendix  C.  The 
guidelines  are  intended  to  supplement  developer-selected  guidelines  for 
implementing  a  TCB  as  well  as  general-purpose  Ada  programming  guidelines. 

Examples  of  Ada  code  are  presented  in  Appendices  B  and  C.  In  Appendix  B,  the 
code  examples  typically  illustrate  why  the  use  of  a  specific  Ada  construct  must 
be  limited  in  a  particular  fashion  if  that  construct  is  to  be  used  in  a  TCB.  The 
examples  in  Appendix  c  illustrate  how  particular  constructs  can  be;  used  in  the 
development  of  a  TCB. 


Key  terms  that  are  used  in  this  document  are  listed  in  Section  5.0,  and  the 
bibliography  is  in  Section  6.0.  Because  each  appendix  is  intended  to  be  a  stand¬ 
alone  document,  each  also  contains  a  key  terms  section  and  a  bibliography. 

This  report  does  not  imply  that  software  alone  is  sufficient  for  ensuring 
security  in  a  TCB.  As  discussed  in  the  papers  "Secure  Computing:  The  Secure  Ada 
Target  Approach,"  "LXKing  Computers  Securely,"  and  "IDCS/ix:  On  Implementing 
Unix  on  the  LOCK  TCB,"  the  security  of  a  system  cannot  be  insured  with  software 
alone.  Hardware  is  fundamentally  important  to  TCB  system  security.  This  report 
does  not  discuss  hardware  aspects  of  TCB-  systems.  If  the  reader  wishes  to 
investigate  the  hardware  issues,  he  should  consult  the  references  cited  above. 
An  abstract  for  each  is  presented  in  Appendix  D. 

This  study  is  somewhat  similar  to  reports  written  on  the  development  of  the  Army 
Secure  Operating  System  (ASOS) . 
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The  analysis  of  Ada  for  security  performed,  by  TRW  in  its  development  of  the  Amy 
Secure  Operating  System  (ASOS)  has  a  different  objective  and  viewpoint  than  that 
of  this  study  on  the  use  of  Ada  in  trusted  ccxnputing  bases  (TCBs) .  The  TRN 
analysis  is  documented  in  its  final  report,  Multilevel  Secure  Operating  System 
Final  Development  Specification  Rationale  for  the  Army  Secure  Operating  System 
(ASOS) .  The  introduction  of  Chapter  5,  "Analysis  of  Ada  for  Security, "  states 
the  following: 

"This  study  partitions  the  problems  concerning  Ada  and  security  into  the 
following  three  categories:" 

a.  "Problems  that  arise  from  the  A1  requirement  .  .  .  to  do  code 
correspondence,  i.e. ,  to  shew  the  correspondence  between  the 
formal  top  level  specifications  and  the  source  code  that 
implements  these  specifications." 

b.  "Problems  that  arise  from  Ada's  need  for  an  elaborate  runtime 
support  library." 

c.  "Problems  that  arise  from  the  (beyond  Al)  considerations  of  Ada 
code  verifications." 

In  contrast  this  study  attempts  to  identify  Ada  software  development  guidelines 
for  creating  trusted  Ada  code  for  TCBs.  It  does  not  address  TCBs  above  the  B3 
class.  Therefore  it  did  not  attempt  to  identify  benefits,  deterrents,  and 
guidelines  with  the  criteria  of  Ada  code  correspondence  with  formal 
specif ications  and  formal  Ada  code  verification  (i.e. ,  items  a  and  c  above) .  Nor 
does  tliis  study  use  the  criterion  of  mulnimizing  the  size  of  the  runtime  support 
library  in  the  development  of  the  security  kernel  (i.e.,  the  reference  monitor). 
Unlike  the  ASOS  this  study  makes  no  distinction  between  Ada  constructs  that  are 
allowed  inside  and  outside  of  a  TCB's  security  kernel. 

Despite  the  differences  between  the  two  studies,  they  are  not  inconsistent  with 
each  other.  Rather  they  complement  each  other.  Many  similar  guidelines  appear 
in  the  two  studies.  Pertinent  ASOS  guidelines  have  been  borrowed  and 
incorporated  into  this  report  and  are  indicated  as  such. 


2.0  RELATING  THE  TCSBC  TO  THE  SOFTWARE  EEVELDEWENT  HCCESS 


2.1  Background 

Hie  first  step  in  developing  Ada  programming  guidelines  for  software  to  which  the 
TCSEC  is  to  be  applied  is  to  map  the  TCSEC  to  the  software  development  process. 
This  is  to  assure  that  the  relationship  between  elements  of  the  software 
development  process  and  the  specific  TCSEC  criteria  are  understood.  Because  this 
mapping  is  language  independent,  Ada  is  not  specifically  mentioned  in  the 
mapping.  The  details  of  the  mapping  are  contained  in  Appendix  A,  "A  Mapping  from 
the  Trusted  Ocrputer  System  Evaluation  Criteria  (TCSEC)  to  the  Software 
Development  Process." 

The  intent  of  this  process  is  to  detail  what  must  be  accomplished  at  each  stage 
of  a  software  development  to  optimize  the  certification  of  a  system  using  the 
Department  of  Defense  TCSEC.  This  optimization  is  from  two  perspectives:  one  is 
to  ensure  that  the  certification  process  meets  the  objective  of  understanding 
what  the  software  product  will,  and  will  not,  do;  the  other  is  to  reduce  the 
effort  required  to  perform  the  certification  process. 

The  intent  of  this  section  is  to  enable  the  reader  to  better  use  the  mapping  in 
Appendix  A.  The  first  area  discussed  in  this  section  is  the  life  cycle  model 
used  for  the  purposes  of  this  report.  The  next  section  contains  general  comments 
on  software  development  that  are  germane  to  developing  software  that  is  to  be 
certified  using  TCSEC. 

2.2  life  Cycle  Description 

Several  models  of  the  software  development  life  cycle  exist.  These  include  the 
waterfall  model,  articulated  by  DoD-STT>-2167A  Defense  System  Software 
Development,  and  the  incremental  development  model  represented  by  Dr.  Barry 
Boehm's  spiral  development  model  [Boehm  1988].  The  primary  difference  between 
these  models  is  that  the  waterfall  model  assumes  that  one  phase  of  development  is 
completed  prior  to  cxamnencement  of  the  next  phase,  whereas  incremental 
development  iterates  between  phases  and  leads  to  partial  system  development  with 
increments  to  the  system  being  preplanned. 

Rather  than  focusing  on  the  distinctions  between  these  two,  or  other,  development 
models,  this  document  assumes  that  systems  pass  through  specific  phases  during 
their  development  and  operational  life  cycles.  Regardless  of  whether  these 
phase?  arc  entered  only  once  during  a  development  or  are  entered  iteratively,  the 
phases  are  adequately  generic  to  be  used  here.  The  five  phases  used  are  the 
following: 


1. 

Requirements 

2. 

Hoci  m 
- 

3. 

Coding 

4. 

Testing 
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5.  Support 

These  phases  aze  used  to  structure  the  guidance  as  to  what  is  to  be  acccaiplished 
during  software  development  to  optimize  the  certification  process.  A  checklist 
of  specific  accomplishments  is  provided  in  Appendix  A  for  each  of  these  five 
phases.  The  checklists  are  developed  to  provide  maximum  latitude  on  hew  each 
item  is  to  be  implemented.  This  is  to  ensure  that  no  development  methodology  is 
either  the  required  or  the  imp?  ied  standard.  Following  each  checklist  is  a 
textual  ejqplanation  of  the  items  on  the  list. 

2.3  General  Garments  cn  the  Software  Development  Process 

This  research  effort  focuses  on  software  development,  which  is  an  element  of 
system  development.  Although  the  results  of  this  effort  will  be  applicable  to 
system  developers,  these  results  are  specifically  targeted  to  software 
developers.  Therefore,  terms  that  can  be  applied  to  system  development  or 
software  development  should  be  interpreted  from  the  software  development 
perspective. 

The  software  development  process  for  certified  systems  will  not  vary 
significantly  from  that  for  conventional  systems.  The  process  will  be 
accomplished  through  the  carpletion  of  various  software  development  phases 
including  the  requirements  phase,  the  design  phase,  the  coding  phase,  the  testing 
phase,  and  the  support  phase.  Each  of  these  phases,  as  detailed  in  Section  2.2, 
progresses  as  in  the  development  of  conventional  systems  with  some  additional 
considerations-  such  as  the  use  of  defensive  programming  and  defensive  testing 
approaches.  These  additional  considerations  will  aid  the  software  developer  by 
providing  assistance  either  to  assure  that  the  goals  of  the  TCSEC  are  met,  to 
implement  the  TCSEC  criteria,  or  to  enhance  an  existing  system  without  requiring 
excessive  effort  in  re-certification.  In  particular,  the  design  phase,  the 
coding  phase,  and  the  testing  phase  each  require  additional  consideration  during 
the  software  development  of  a  TCB. 


During  the  design  phase  of  software  development,  the  software  developer  must  use 
a  design  methodology  that  is  compatible  with  the  requirements  analysis.  By 
ensuring  this  compatibility,  the  software  developer  can  ensure  that  there  will  be 
traceability  between  the  requirements  and  the  design.  This  traceability  will 
demonstrate  the  completeness  of  the  system  software,  which,  in  turn,  guarantees 
that  all  software  requirements  are  addressed  in  the  design. 

In  addition,  during  the  design  phase  of  the  software  development,  the  developer 
needs  to  identify  the  various  protection  mechanisms  that  will  be  implemented 
during  development.  Errors  and  emissions  are  the  leading  causes  of  security 
breaches,  and  these  can  be  addressed  by  design  reviews  and  code  walkthroughs,  for 
example.  Whatever  protection  mechanisms  are  to  be  implemented,  the 
implementation  details  must  be  determined  during  the  design  phase,  and  an 
appropriate  design  must  be  established. 

The  coding  phase  of  the  software  development  of  TCBs,  differs  from  that  of 
conventional  systems,  primarily,  in  that  the  programmer  must  be  particularly 
attentive  to  the  use  of  coding  standards  that  promote  and  do  not  ccarpromise  the 
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code's  integrity.  When  coding  a  conventional  system  the  programmer  attempts  to 
satisfy  the  requirements  as  stated  in  the  software  requirements  documentation. 
These  requirements  identify  both  the  data  to  be  handled  by  the  system  and  the 
operations  required  to  handle  the  data.  However,  although  a  TCB's  software 
requirements  document  contains  the  same  types  of  information  as  that  for  a 
conventional  system,  the  developer  of  a  TCB  must  also  code  in  a  manner  so  that 
the  operations  are  implemented  so  as  not  to  cctprcmise  the  data  for  which  the  TCB 
is  responsible.  For  example,  if  users  of  types  X,  Y,  and  Z  should  be  allowed  to 
perform  operation  A,  then  when  coding  operation  A,  the  software  developer  needs 
to  create  the  software  to  check  the  type  of  the  user  to  ensure  not  only  that  it 
is  one  of  type  X,  Y,  or  Z,  but  also  that  it  is  not  one  of  the  other  types  of 
users. 

Dishonest  and  disgruntled  enployees  are  major  threats  to  developing  secure 
•systems.  Management  must  make  every  effort  to  ensure  that  the  programmers  are 
adequately  screened  prior  to  their  involvement  with  a  trusted  system.  The  extent 
of  the  required  background  checks  of  the  employees  is  a  function  of  the 
sensitivity  of  the  system.  The  more  sensitive  the  system,  the  more  thorough  the 
background  check  must  be.  Also,  monitoring  of  programmer  attitudes  during 
development  is  necessary  to  identify  potential  personnel  problems  early. 
Although  various  techniques  exist  to  ensure  the  consistency  between  the  design 
and  code  of  a  system  and  to  ensure  the  necessity  and  function  of  sections  of 
code,  these  techniques  are  far  fran  being  perfected.  Because  there  is  no 
technical  mechanism  that  provides  assurance  that  malicious  code  nas  not  been 
introduced,  background  checks  and  monitoring  programmer  attitudes  are  necessary 
complements  to  software  development  practices. 

Finally,  during  the  testing  phase  for  certified  systems,  the  testing  process  goes 
beyond  that  for  traditional  software.  In  addition  to  testing  to  ensure  that  the 
software  supports  appropriate  users  and  uses,  the  software  must  deny  access  to 
inappropriate  users  and  not  support  inappropriate  uses.  Safeguards  against 
accidental  access  to  system  data,  against  disclosing  information  about  the 
system'' s  structure,  and  against  providing  information  about  system  users  must  be 
tested.  The  testing  must  assure  that  accidental  or  intentional  system  misuse 
does  not  compromise  the  security  of  the  system,  its  data,  or  its  users.  Knowing 
that  the  testing  process  for  certified  systems  goes  beyond  that  for  conventional 
systems,  the  design  of  certified  systems  must  support  these  testing  needs.  An 
initial  step  is  to  inform  the  system  designers  of  the  testing  requirements  of  the 
system  so  that  the  design  supports  the  testing  of  safeguards.  In  addition,  test 
hooks  may  be  designed  into  the  system,  where  the  purpose  of  the  hooks  is  to 
support  the  testing  process. 

The  intent  of  this  project  is  to  be  unbiased  toward  the  various  Ada  design 
methodologies;  therefore,  Ada  design  issues  raised  in  the  reports  should  apply  to 
all  Ada  design  methodologies.  Items  included  are  various  Ada  facilities  that  aid 
good  software  development,  such  as  the  use  of  packages,  subprograms,  data  -types 
"{especially  private  types) ,  etc. ,  for  information  hiding,  modularity,  and  data 
abstraction. 
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2.4  Fbooat  of  the  Happing 


The  format  of  Appendix  A  follows  Fart  I  of  the  TCSEC.  Each  TCB  class,  frcm  Cl 
through  B3,  is  described.  The  four  asajor  stjbhesdings  of  TC3s,  Security  Policy, 
Aocountabil ity ,  Assurance,  and  Documentation,  are  then  presented,  with  a  synopsis 
of  the  certification  criteria  for  each.  Each  subheading  contains  a  checklist  of 
activities  for  each  of  the  five  phases  of  the  software  development  process. 
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3,0  mnssmE  for  tee  FsasRamras  guxdelehes 


3.1  Badftgrorn & 

The  first  step  in  developing  Ada  prograMting  guidelines  for  software  to  which  the 
TCSEC  is  to  be  applied  was  to  imp  the  TCSEC  to  the  software  development  process. 
The  second  was  to  develop  tive  rationale  on  which  the  guidelines  are  to  be  based. 
The  rationale  for  the  guidelines  are  the  benefits  and  potential  deterrents  of  the 
Ada  programing  language  relative  to  the  *iesds  of  the  TCSEC. 

One  intent  of  the  rationale  is  to  identify  benefits  of  using  Ada  in  the  software 
development  of  TCBs.  These  benefits  include  Ma’s  assets  in  the  application  of 
sound  software  engineerirsg  principles,  such  as  data  abstraction,  information 
hiding,  modularity,  and  localization.  Also  included  among  the  benefits  are  such 
Ada  constructs  as  strong  data  typing,  packages,  subprograms,  and  tasks. 

Another  intent  of  the  rationale  is  to  identify  and  categorize  potential 
deterrents  of  using  Ma  in  the  software  development  of  TCBs.  These  include 
shortcomings  inherent  to  programing  languages  in  general ;  shortcordngs  unique  to 
the  Ada  language;  and  benefits  of  using  tools  in  the  development  of  Ada  language 
software. 


3.2  Format  of  Rationale 

The  rationale  for  the  guidelines  are  presented  in  Appendix  B,  Benefits  of  and 
Potential  Deterrents  to  Using  Acte  in  the  Software  Development  Process  of  Trusted 
Computing  Bases.  The  rationale  are  presented  frora  two  perspectives.  First,  the 
Ada  language  is  considered  by  focusing  on  the  foil  wing  issues:  (1)  Benefits  of 
using  Ada  in  developing  TCB  systems,  {2}  Potential  deterrents  to  using  Ada  in 
developing  TCB  systems,  (3)  Shortemings  inherent  to  programming  languages  in 
general  in  developing  TCB  systems,  (4)  Shortcomings  unique  to  the  Ate  language  in 
developing  TCB  systems,  (5)  Benefits  of  using  tools  for  developing  Ada  software 
for  TCB  systems.  The  rationale  also  presents  these  issues  in  the  context  of  a 
mapping  of  Ada  usage  to  generalized  TCB  criteria.  In  particular,  Class  B3  is 
used  as  a  template  for  the  generalized  TCB  criteria.  Ada  constructs  and  features 
are  identified  that  my  be  used  to  implement  TCB  functions  and  features. 


3.3  Conclusions 

Because  Ada  was  designed  with  features  and  constructs  that  promote  recognized 
sound  software  engineering  principles  sore  than  other  current  high  order 
languages  (HOLs) ,  it  is  well  suited  as  the  implementation  language  of  TCBs. 
Although  Ada  offers  various  specific  benefits,  the  potential  deterrents  of  using 
Ada  must  be  recognized  and  addressed.  Although  these  potential  problems  were 
identified  with  using  various  Ada  features,  this  is  not  meant  to  imply  that  any 
of  the  features  should  not  be  used.  Rather,  the  security  of  the  TCB  must  not  be 
compromised,  as  discussed  in  Appendix  B,  whan  any  of  the  constructs  and  features 
are  used  in  the  implementation  of  the  TCB. 
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4.0  USE  OF  THE  GJHELTNES 

4.1  Cbjective?  Ftarmat,  and  Scope  of  the  Guidelines 

The  guidelines  presented  in  Appendix  C.  Programming  Guidelines  for  Using  Ada  in 
the  Software  Development  of  TC3s,  have  a  very  specific  focus.  That  focus  is  to 
assist  developers  who  are  both  e^eriencad  with  the  TCSEC  and  knowledgeable  of 
Ada  in  merging  these  two  technologies.  The  objective  of  the  guidelines  is 
twofold: 

1.  Provide  direction  on  the  use  of  particular  Ada  constructs 

2.  Provide  recommendations  on  hew  to  implement  specific  TCSEC  criteria 
with  Ada. 

Because  of  this  dual  objective,  the  guidelines  are  presented  using  two 
frameworks.  The  first  presentation  is  a  listing  of  the  chapters  and  sections  of 
The  Reference  Manual  for  the  Ada  Programming  language  (LRM)  [ANSI/MI^STD~1815A~ 
1983],  and  descriptions  and  guidelines,  where  appropriate,  on  the  use  of  sections 
for  TCSEC  software.  The  second  presentation  is  a  listing  of  the  criteria  of  the 
TCSEC,  using  B3  criteria  as  a  template,  with  guidelines  on  how  to  implement  the 
criteria  using  Ada. 

The  scope  of  these  guidelines  is  specific  to  the  TCSEC  and  to  the  Ada  programming 
language.  The  guidelines  would  be  best  used,  therefore,  in  conjunction  with 
internal  company  standards  for  software  engineering  of  TCBs  and  for  software 
engineering  with  Ada.  Modularization,  for  example,  is  a  key  software  engineering 
principle  that  should  be  incorporated  into  a  system  design.  Specific  TCSEC 
criteria  whose  implementation  is  facilitated  by  modularization  are  noted.  The 
Ada  structures  that  could  be  used  for  modularization  to  support  the  specific 
criteria  are  listed. 

These  guidelines  are,  therefore,  intended  to  complement  other  standards,  not  to 
stand  alone.  Specifically,  developer-selected  guidelines  for  implementing  a  TCB 
as  well  as  general-purpose  Ada  programming  guidelines  should  be  supplemented 
with,  not  supplanted  by,  these  guidelines. 

4.2  Limitations  of  the  language  Constructs 

The  Ada  language  is  rich  and  powerful  in  its  programming  constructs.  With  this 
breadth  of  constructs  cones  the  potential  to  write  software  that  is  difficult  to 
understand  and  control.  (^currency,  for  example,  is  necessary  in  several 
applications.  Concurrent  software,  however,  is  very  difficult  to  test, 
understand  and  predict.  The  Ada  construct  for  implementing  concurrent  processes 
is  the  Ada  task.  TCSEC  software  must  be  testable,  understandable,  and 
predictable.  Also,  many  secure  applications  require  concurrent  processes.  The 
guidelines  cannot  realistically  recomnend  that  tasks,  for  example,  never  he  used. 
Instead,  they  list  where  tasks  are  appropriate  and  they  discuss  hew  tasks  are  to 
be  implemented  to  minimize  the  potential  negative  effects  of  using  tasks.  The 
guidelines  do  not  recommend  prohibiting  the  use  of  any  construct  but  rather,  in 
some  cases,  recommend  limits  on  hew  constructs  are  to  be  used. 
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Constructs  ether  them  taste  have  both  advantages  and  disadvantages.  A  typical 
tradeoff  is  between  irxart.ry  usage  efficiency  and  execution  time  efficiency. 
Dynamic  memory  structures,  for  example,  are  typically  efficient  from  the  memory 
usage  perspective  but  inefficient  from  the  execution  timing  perspective.  The 
guidelines  state  the  tradeoffs  involved  in  using  Various  cxsnstructs  to  facilitate 
application-specific  decisions. 
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5.0  KE5f  TERMS 


Several  key  words  appear  throughout  the  text  of  this  document.  These  words  have 
specific  meanings  within  the  context  of  certified  systems,  and  their  definitions 
are  presented  here. 

These  definitions  are  taken  directly  from  the  TCSEC: 

Access  -  A  specific  type  of  interaction  between  a  subject  and  an  object  that 
results  in  the  flow  of  information  from  one  to  the  other. 

Audit  Trail  -  A  set  of  records  that  collectively  provide  documentary  evidence  of 
processing  used  to  aid  in  tracing  from  original  transactions  forward  to 
related  records  and  reports,  and/or  backwards  from  records  and  reports  to 
their  component  source  transactions. 


Covert  Charnel  -  A  ccmmunication  channel  that  allows  a  process  to  transfer 
information  in  a  manner  that  violates  the  system's  security  policy. 

Data  -  Information  with  a  specific  physical  representation . 

Discretionary  Access  Control  -  A  means  of  restricting  access  to  objects  based  on 
the  identity  of  subjects  and/or  groups  to  which  they  belong.  The  controls 
are  discretionary  in  the  sense  that  a  subject  with  a  certain  access 
permission  is  capable  of  passing  that  permission  (perhaps  indirectly)  on  to 
any  other  subject  (unless  restrained  by  mandatory  access  control) . 

Mandatory  Access  Control  -  A  means  of  restricting  access  to  objects  based  on  the 
sensitivity  (as  represented  by  a  label)  of  the  information  contained  in  the 
objects  and  the  formal  authorization  (i.e. ,  clearance)  of  subjects  to  access 
information  of  such  sensitivity. 

Object  -  A  passive  entity  that  contains  or  receives  information.  Access  to  an 
object  potentially  implies  access  to  the  information  it  contains.  Examples 
of  objects  are:  records,  blocks,  pages,  segments,  files,  directories, 
directory  trees,  and  programs,  as  well  as  bits,  bytes,  words,  fields, 
processors,  video  displays,  keyboards,  clocks,  printers,  network  nodes,  etc. 

Sensitivity  label  -  A  piece  of  information  that  represents  the  security  level  of 
an  object  and  that  describes  the  sensitivity  (e.g. ,  classification)  of  the 
data  in  the  object.  Sensitivity  labels  are  used  by  the  TCB  as  the  basis  for 
mandatory  access  control  decisions. 

Subject  -  An  active  entity,  generally  in  the  form  of  a  person,  process,  or  device 
that  causes  information  to  flew  among  objects  or  changes  the  system  state. 
Technically,  a  process/dcmain  pair. 


Trusted  Computing  Base  (TCB)  -  The  totality  of  protection  mechanisms  within  a 
computer  system  —  including  hardware  firmware,  and  software  —  the 
combination  of  which  is  responsible  for  enforcing  a  security  policy.  A  TCB 
consists  of  one  or  more  components  that  together  enforce  a  unified  security 
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policy  over  a  product  or  system.  The  ability  of  a  TCB  to  correctly  enforce 
a  security  policy  depends  solely  on  the  mechanisms  within  the  TCB  and  on  the 
correct  input  by  system  administrative  personnel  of  parameters  (e.g. ,  a 
user's  clearance)  related  to  the  security  policy. 


Additional  Terms 

These  terms  are  included  because  they  appear  frequently  in  the  following  text. 

Pragma  -  A  compiler  directive.  That  is,  it  "is  used  to  convey  information  to 
the  compiler."  According  to  the  Ada  language  reference  manual  [ANSI/MIIr- 
STD-1815A-1983],  the  predefined  pragmas  (Refer  to  Annex  B  in  this  manual  for 
descriptions)  "must  be  supported  by  every  implementation .  In  addition,  an 
implementation  may  provide  implementation-defined  pragmas,  which  must  then 
be  described  in  Appendix  F",  i.e. ,.  the  appendix  on  impleroentatian-depandent 
characteristics  that  the  Ada  compiler  vendor  must  provide  in  his  Ada 
language  reference  manual. 

Security  -  The  protection  of  computer  hardware  and  software  from  accidental  or 
malicious  access,  use,  modification,  destruction,  or  disclosure.  Security 
also  pertains  to  personnel,  data,  communications ,  and  the  physical 
protection  of  computer  installations  [IEEE  1983].  Specifically,  for  the 
purposes  of  this  report,  security  is  defined  by  the  criteria  in  the  TCSEC, 
i.e.,  a  given  security  problem  corresponds  with  a  specific  TCSEC  criteria. 
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1.1  Backgrcasrid 

The  intent  of  this  appendix  is  to  detail  what  exist  be  accomplished  at  each  stage 
of  a  software  development  to  optimize  the  certification  of  a  system  using  the 
Department  of  Defense  TCSEC.  'Ihis  optimization  is  from  two  perspectives:  one  is 
to  ensure  tiiat  the  certification  process  meets  the  objective  of  understanding 
what  the  software  product  vri.il,  and  will  not,  do,*  the  other  is  to  reduce  the 
effort  required  to  perform  the  certification  process.  Because  this  mapping  is 
language  independent,  Ma  is  not  mentioned  in  the  body  of  the  this  Appendix. 

'Ihis  appendix  is  meant  to  stand  alone;  however,  a  strong  familiarity  with  the 
TCSEC  is  lec? lined  to  use  the  document. 


1.2  Life  Cycle  Description 

Several  models  of  the  software  development  life  cycle  exist.  These  include  the 
waterfall  model,  articulated  by  DoD-SrD>2167A.  Defense  System  Software 
Development,  and  the  incremental  development  model  represented,  by  Dr.  Barry 
Boehm's  spiral  development  model  [Boehm  1988].  The  primary  difference  between 
these  models  is  that  the  waterfall  model  assumes  that  one  phase  of  development  is 
completed  prior  to  exmraencement  of  the  next  phase,  whereas  incremental 
development  iterates  between  phases  and  leads  to  partial  system  development  with 
increments  to  the  system  being  preplanned. 

Rather  than  focusing  on  the  distinctions  between  these  two,  or  other,  development 
models,  this  document  assumes  that  systems  pass  through  specific  phases  during 
their  development  and  operational  life  cycles.  Regardless  of  whether  these 
phases  are  entered  only  once  during  a  development  or  are  entered  iteratively,  the 
phases  are  adequately  generic  to  be  used  to  structure  this  report.  The  five 
phases  used  here  are  the  following: 

1.  Requirements 

2.  Design 

3.  Coding 

4.  Testing 

5.  Support 

These  phases  are  used  to  structure  the  guidance  as  to  what  is  to  be  accomplished 
during  software  development  to  optimize  the  certification  process.  A  checklist 
of  specific  accciiplishments  is  provided  for  each  of  these  five  phases.  The 
checklists  are  developed  to  provide  maximum  latitude  on  how  each  item  is  to  be 
implemented.  This  is  to  ensure  that  no  development  methodology  is  either  the 
required  or  the  implied  standard.  Follcwirsg  each  checklist  is  a  textual 
explanation  of  the  items  on  the  list. 
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1.3  Key  Terms 


Several  key  words  appear  throughout  the  text  of  this  appendix.  These  words  have 

specific  meanings  within  the  context  of  certified  systems  and  their  definitions 

are  presented  here.  These  definitions  are  taken  directly  from  the  TCSEC: 

Access  -  A  specific  type  of  interaction  between  a  subject  and  an  object  that 
results  in  the  flew  of  information  from  one  to  the  other. 

Audit  Trail  -  A  set  of  records  that  collectively  provide  documentary  evidence  of 
processing  used  to  aid  in  tracing  from  original  transactions  forward  to 
related  records  and  reports,  and/or  backwards  from  records  and  reports 
to  their  component  source  transactions. 

Covert  Charnel  -  A  cctrtmmication  channel  that  allows  a  process  to  transfer 
information  in  a  manner  that  violates  the  system’s  security  policy. 

Data  -  Information  with  a  specific  physical  representation. 

Discacetionary  Access  Control  ~  A  means  of  restricting  access  to  objects  based  on 
the  identity  of  subjects  and/or  groups  to  which  they  belong.  The 
controls  are  discretionary  in  the  sense  that  a  subject  with  a  certain 
access  permission  is  capable  of  passing  that  permission  (perhaps 
indirectly)  on  to  any  other  subject  (unless  restrained  by  mandatory 
access  control) . 

Mandatory  Access  CJontrol  -  A  means  of  restricting  access  to  objects  based  on  the 
sensitivity  (as  represented  by  a  label)  of  the  information  contained  in 
the  objects  and  the  formal  authorization  (i.e. ,  clearance)  of  subjects 
to  access  information  of  such  sensitivity. 

Object  -  A  passive  entity  that  contains  or  receives  information.  Access  to  an 
object  potentially  irplies  access  to  the  information  it  contains. 
Examples  of  objects  are:  records,  blocks,  pages,  segments,  files, 
directories,  directory  trees,  and  programs,  as  well  as  bits,  bytes, 
words,  fields,  processors,  video  displays,  keyboards,  clocks,  printers, 
network  nodes,  etc. 

Sensitivity  label  -  A  piece  of  information  that  represents  the  security  level  of 
an  object  and  that  describes  the  sensitivity  (e.g. ,  classification)  of 
the  data  in  the  object.  Sensitivity  labels  are  used  by  the  TCR  as  the 
basis  for  mandatory  access  control  decisions. 

Subject  -  An  active  entity,  generally  in  the  form  of  a  person,  process,  or  device 
that  causes  information  to  flew  among  objects  or  changes  the  system 
state.  Technically,  a  process/dcmain  pair. 

Trusted  Oat  acting  Ease  (TCB)  -  The  totality  of  protection  mechanisms  within  a 
computer  system  —  including  hardware  firmware,  and  ,-aoftware  —  the 
combination  of  which  is  responsible  for  enforcing  a  security  policy.  A 
TCB  consists  of  one  or  more  components  that  together  enforce  a  unified 
security  policy  over  a  product  or  system..  The  ability  of  a  TCB  to 
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correctly  enforce  a  security  policy  depends  solely  on  the  mechanisms 
within  the  TCB  and  an  the  correct  input  try  system  administrative 
personnel  of  parameters  (e.g. ,  a  user's  clearance)  related  to  the 
security  policy. 

Additional  Term 

This  term  is  included  because  it  appears  frequently  in  the  following  text. 

Security  -  The  protection  of  ccrputer  hardware  and  software  fron  accidental  or 
malicious  access,  use,  modification,  destruction,  or  disclosure. 
Security  also  pertains  to  personnel,  data,  ccrminications ,  and  the 
physical  protection  of  computer  installations  [IEEE  1983], 
Specifically,  for  the  purposes  of  this  report,  security  is  defined  by 
the  criteria  in  the  TCSB2,  i.e. ,  a  given  security  problem  corresponds 
with  a  specific  TCSEC  criteria. 
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1.4  Format  of  "Oils  Appendix 


Hie  format  of  this  appendix  follows  the  format  of  Part  I  of  the  TCSEC.  Each 
Class  of  TCB  is  described  through  a  direct  quotation  of  the  description  from  the 
TCSFC.  After  this  description,  each  of  the  four  subheadings, ,  Security  Policy, 
Accountability,  Assurance,  and  Documentation,  follows  with  its  individual 
subheadings,  such  as  Discretionary  Access  Control.  For  each  of  these,  a  synopsis 
of  the  certification  criteria  is  presented,  followed  by  a  checklist  of  activities 
to  be  performed  at  each  of  the  five  phases  of  the  software  development  life 
cycle.  In  those  instances  where  one  or  more  of  the  five  phases  is  not  presented, 
no  special  consideration  needs  to  be  made  during  this  phase  of  the  development. 
In  addition,  the  checklists  for  the  various  subheadings  are  upwardly  compatible, 
i.e. ,  Requirements  for  Discretionary  Access  Control  for  a  class  Cl  TCB  also  apply 
to  the  Requirements  for  Dit  -ret ionary  Access  Control  for  a  class  C2  TCB.  When 
these  checklist  items  are  initially  introduced,  they  are  presented  in  bold- 
underline  and  a  textual  explanation  for  each  is  given.  When  they  are  repeated, 
the/  are  prefixed  by  "  (X) : , "  where  X  is  the  Class  of  TCB  in  which  they  were 
introduced  checklist  items  preceded  by  an  ,!o"  came  directly  from  the  TCSEC;  those 
preceded  by  a  "-,l  were  identified  by  this  research. 

Bold-Underline  is  used  to  indicate  certification  criteria  and  checklist  items  not 
contained  in  a  lewer  class  or  changes  and  additions  to  already  defined 
certification  criteria  or  checklist  items.  Where  there  are  no  bold-underline . 
information  has  been  carried  over  from  .lower  classes  without  addition  or 
modification.  Also,  the  paragraph  numbers  from  this  document  correspond  exactly 
to  those  in  the  TCSEC  to  assist  the  user  of  this  document  in  tracing  a 
requirement  back  to  its  origin  in  the  TCSEC. 
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2.0  DIVTSICK  C:  DISCKETICttAFY  HOIECnCN 

2.1  CLASS  CL:  DISCKEnaaRY  SECURITY  IKHECnCN 

"The  Trusted  Computing  Base  (TCB)  of  a  class  Cl  system  nominally  satisfies  the 
discretionary  security  requirements  by  providing  separation  of  users  and  data. 
It  incorporates  sane  form  of  credible  controls  capable  of  enforcing  access 
limitations  on  an  individual  basis,  i.e.,  ostensibly  suitable  for  allowing  users 
to  be  able  to  protect  project  or  private  information  and  to  keep  other  users  from 
accidentally  reading  or  destroying  their  data.  The  class  Cl  environment  is 
expected  to  be  one  of  cooperating  users  processing  data  at  the  same  level  (s)  of 
sensitivity. " 

2.1.1  Security  Policy 

2. 1.1.1  Discretionary  Access  Control 

o  TTR  shall  define  and  control  access  between  named  users  and  named 
objects  in  the  ADP  system 

o  Enforcement  mechanism  shall  allow  users  to  specify  and  control  sharing 
of  those  objects  by  named  individuals,,  nr  defined  groups,  or  both 

Requirements: 

-  Identify  all  types  of  users  far  the  system,  including  individual  users 
and  groups  of  users 

Identify  all  types  of  objects  fe.q. .  files  and  programs)  in  the  system 
Identify  the  level  of  sensitivity  for  the  data  within  the  system 

-  Describe  all  possible  interactions  between  the  users  and  the  data 
Identify  the  criteria  far  determining  the  need  of  a  particular  user  to 
access  a  particular  object 

To  properly  develop  tne  Discretionary  Access  Control  Requirements  for  a 
Class  Cl  TCB,  the  system  developer  must  completely  evaluate  the  system  to  be 
developed.  This  evaluation  must  identify  all  of  the  types  of  user  objects 
that  are  to  be  handled  by  the  system.  In  addition,  all  interactions  between 
these  users  and  objects  need  to  be  described.  Once  this  information  has 
been  established,  the  security  policy  requirements  for  each  type  of 
interaction  will  be  determined,  and  appropriate  system  requirements  will  be 
developed  to  reflect  this  determination. 

Consider  the  case  of  the  development  of  a  secure  database  system.  In 
particular,  consider  the  user  of  type  data  entry  person,  and  the  data  of 
type  salary  information.  This  data  entry  person  may  be  allowed  to  enter  the 
employee  name  and  identification  number;  however,  the  annual  salary 
associated  with  that  employee  would  be  sensitive  information,  and  as  such 
would  not  be  made  available  to  the  data  entry  person.  In  this  instance,  the 
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security  policy  requirements  for  this  type  of  interaction  would  reflect 
this. 


Design: 


Establish  a  method  fear  maintaining  the  enforcement  merfwnign  fe.rr.  r 
self /group/rubl ic  controls,  access  control  lists! 

Establish  a  method  of  cxritrollinq  access  to  objects  within  the  domain 
of  the  TCB 

Establish  a  criteria  far  determining  the  need  of  a  particular  user  to 

access  a  particular  object 

Establish  a  mechanism  for  identifying  users 

The  design  of  the  discretionary  access  control  for  a  Class  Cl  TCB  must 
satisfy  the  requirements  stated  above.  In  particular,  a  method  for 
enforcing  the  access  control  must  be  established.  In  addition,  a  mechanism 
for  controlling  access  to  objects  within  the  demain  of  the  TCB  needs  to  be 
established,  and  the  design  needs  to  include  a  means  of  identifying  users. 
For  example,  the  discretionary  access  design  may  use  passwords  to  control 
the  access  of  users  to  objects  in  the  TCB.  Only  those  users  on  a  given 
access  list  would  be  informed  of  the  password  required  to  gain  access  to 
data  to  which  the  list  corresponds. 

Coding: 

Use  a  defensive  procn^nmincr  methodology,  including  hooks  to  aid  testing 
and  maintenance 

The  coding  must  implement  the  design  of  the  discretionary  access  control  of 
the  Class  Cl  TCB.  Coding  should  be  performed  defensively,  using  modular 
structured  programming,  as  discussed  in  the  introduction.  The  hooks 
typically  are  prudently  placed  debug  statements  that  provide  information  on 
the  operation  of  the  system.  A  convenient  means  should  be  provided  to  turn 
the  debug  statements  on  and  off. 

Support: 

Re-test  system  upon  cccpleticn  of  modification 
-  Ensure  that  enforcement  mechanism  access  control  lists  are  maintained. 
e.q. ,  adding  new  users  to  the  access  control  lists,  and  removing  users 
from  the  aooess  control  lists  who  no  longer  regm'-n^  anr sprs  to  the 
system 

Support  for  discretionary  access  control  involves  the  maintenance  of  the 
system  such  as  adding  enhancements  to  it  or  removing  obsolete  features.  The 
support  includes  the  maintenance  of  the  access  control  list  by  adding  new 
users  and  removing  users  who  no  longer  require  access  to  the  system. 
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2.1.2  Aoocuntability 

2. 1.2.1  Identification  and  Authentication 


o 

to  Derform  any  other  actions  that  the  TCB  is  exnected  to  mediate 

o 

o 

TCB  shall  protect  authentication  data  so  that  it  cannot  be  accessed  bv 

any  unauthorized  user 

Requirements: 

-  Identify  all  actions  to  be  mediated  by  the  TCB,  including  aonpss  to 
authentication  data 

-  Define  a  standard  format  for  authentication  data 
Determine  a  method  for  identifying  users 

The  major  criterion  to  be  met  when  establishing  the  requirements  for 
Identification  and  Authentication  of  a  Class  Cl  TCB  is  that  users  must 
identify  themselves  to  the  TCB  before  beginning  to  perform  any  actions  to  be 
mediated  by  the  TCB.  To  accurately  develop  requirements  for  this,  the 
developer  needs  to  first  establish  a  method  for  identifying  users,  and 
second  establish  a  list  of  all  actions  to  be  mediated  by  the  TCB. 

The  method  for  identifying  lasers  would  vary  depending  upon  the  number  of 
users  requiring  access  or  the  sensitivity  of  the  data  within  the  system. 
For  example,  if  the  system  contained  very  little  private  information,  the 
developer  may  decide  to  implement  somewhat  trivial  identification  procedures 
for  those  actions  that  access  the  non-private  information  and  more 
restrictive  identification  procedures  for  those  actions  that  access  the 
private  information.  If  all  of  the  information  were  private,  restrictive 
identification  procedures  would  be  used  in  all  cases.  Regardless  of  the 
identification  procedures  used,  authentication  data  would  be  used  to  verify 
the  user's  identify.  The  format  for  this  authentication  data  (e.g.,  a 
password  and  a  social  security  number)  will  need  to  be  determined  at  this 
time. 


Design: 

-  Establish  a  protected  mechan-ian  for  identification  and  authentication 
of  users 

Establish  a  mPThanisan  for  creating  and  maintaining  authentication  data 

The  Design  of  the  Identification  and  Authentication  aspect  of  a  Class  Cl  TCB 
must  be  responsible  for  the  actual  identification  of  the  users.  To  do  this, 
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a  mechanism  for  identifying  the  users  and  authenticating  their 
identification  must  be  designed.  Furthermore,  a  mechanism  for  creating, 
maintaining,  and  protecting  the  authentication  data  needs  to  be  designed  to 
guarantee  that  the  data  is  properly  maintained  and  is  tamper-proof.  This 
mechanism  will  be  protected  by  the  TCB,  so  that  no  user  can  accidentally 
access  it  and  read,  modify,  or  delete  important  authentication  data. 


2.1.3  Assurance 
2. 1.3.1  Operational  Assurance 
2. 1.3. 1.1  System  Architecture 

o  'TOR  shall  maintain  a  dmain  for  its  own  execution  that  protects  it  from 
external  interference  or  tampering 

o  Resources  controlled  by  the  TCB  may  be  a  defined  subset  of  the  subjects 
and  objects  in  the  ADP  system 

Requirements: 

-  Identify  all  rasouroes  to  be  protected  by  the  TCB  including  tlie  TCB 
code  and  data  structures 

To  develop  the  requirements  for  the  System  Architecture  in  a  Class  Cl  TCB, 
all  resources  that  the  TCB  must  protect  need  to  be  identified.  These 
resources  include  the  code,  data  structures,  and  files  in  the  TCB's  domain. 
Protecting  the  resources  will  serve  to  isolate  them  from  external 
interference  and  tampering,  and  thus  ensure  their  integrity.  Resources  may 
require  various  methods  of  protection. 

Design: 

-  Establish  a  mode  for  protecting  each  resource  within  the  TCB 

The  System  Architecture  design  for  a  Class  Cl  TCB  must  establish  a  mode  for 
protecting  each  resource  within  the  TCB.  Such  a  mode  may  vise  security 
mechanisms,  such  as  passwords,  to  restrict  access  to  resources  like  its 
code.  Hardware  security  mechanisms  may  be  used  to  provide  protection  for 
some  resources  (e.g. ,  descriptors  that  identify  the  security  attributes  of 
the  subject  and  object,  and  gates  that  control  access  to  resources) . 
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2. 1.3. 1.2  System  Integrity 

o  Hardware  snd/or  software  features  shall  be  provided  that  can  be  used  to 
periodically  validate  the  correct  operation  of  the  cn-site  hardware  and 
firmware  elements  of  the  TCB 


Requirements: 

Identify  hardware  and  firmware  elements  of  the  TCB  to  be  validated 
-  Determine  validation  criteria  for  testing  each  element  of  the  TCB 

Determine  the  appropriate  interval  at  which  validation  of  tlie 

hardware/fintware  should  take  place 

To  correctly  detail  requirements  for  System  Integrity  of  a  Class  Cl  TCB,  the 
system  developer  must  identify  all  on-site  hardware  and  firmware  elements  of 
the  TCB.  In  addition,  the  criteria  for  determining  validity  of  these 
elements  need  to  be  established.  When  establishing  the  validation 
criterion,  each  hardware  and  firmware  element  needs  to  be  considered 
individually,  rather  than  by  type  of  element,  because  the  validation  of 
these  elements  is  dependent  upon  their  operation  environment.  As  an  example 
of  this,  consider  a  tape  drive  on  the  system.  If  this  tape  drive  were  used 
to  backup  a  file  containing  non-sensitive  data,  its  validation  criteria 
would  be  less  strict  than  those  developed  if  it  were  used  to  back  up 
sensitive  data;  however,  the  type  of  tape  drive  would  be  the  same  in  both 
instances. 


Design; 

“  Establish  a  method  for  testing  each  criterion  for  each  elonent  of  the 
TCB 

As  described  in  the  System  Integrity  Requirements,  it  is  important  to 
consider  not  only  the  type  of  the  hardware  being  validated,  but  also  its 
place  in  the  operation  of  the  TCB.  Because  of  this,  it  is  necessary,  during 
the  design  phase,  for  the  developer  to  completely  understand  each  validation 
criteria  for  each  piece  of  hardware  and  to  design  each  test  individually. 
While  it  is  true  that  seme  tests  may  be  able  to  be  used  for  evaluating 
similar  criteria  on  similar  pieces  of  hardware,  the  criteria  need  to  be 
evaluated  separately  and  tests  created  separately  to  ensure  that,  once 
developed,  they  are  complete  and  test  exactly  what  needs  to  be  validated. 
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2. 1.3. 2  Life-Cycle  Assurance 
2. 1.3. 2.1  Security  Testing 

o  Security  mechanisms  the  ADP  system  shall  he  tested  and  found  to  work 
as  claimed  in  the  system  documentation 

o  Testing  shall  he  dene  to  assure  that  there  are  no  obvious  wavs  for  an 
unauthorized  user  to  bypass  or  otherwise  defeat  the  security  protection 
mechanisms  of  the  TCB 

Requirements: 

Identify  security  protection  mechamcans  nf  the  TCB  to  be  tested 

Ihe  performance  of  security  testing  in  a  Class  Cl  TCB  ensures  the  integrity 
of  the  system's  security.  Ihe  system  documentation  serves  as  the  basis  for 
identifying  the  security  protection  mechanisms  (e.g. ,  discretionary  access 
control)  to  be  tested.  To  perform  this  testing,  all  security  protection 
mechanisms  with  the  TCB  need  to  be  identified. 

Design: 

-  Establish  a  means  of  testing  each  security  protection  mechanism 

Ihe  design  of  the  security  testing  features  for  a  Class  Cl  TCB  must  satisfy 
the  requirement  stated  above.  This  is  confirmed  by  demonstrating  that  the 
system's  security  complies  with  the  system  documentation.  This  design  needs 
to  provide  a  means  of  testing  each  security  protection  mechanism  for  which 
it  is  responsible.  Ihis  may  be  accomplished  by  examining  the  data  that 
results  from  the  execution  of  diagnostic  testing. 

Coding: 

Use  prudently  placed  debug  statements  to  allow  the  tester  to  monitor 
the  operation  of  the  security  mechanisms 

Ihe  coding  must  implement  the  design  of  security  testing  features  of  the 
Class  Cl  TCE.  In  particular,  the  diagnostics  may  be  derived  from  prudently 
placed  debug  statements  to  allow  the  tester  to  monitor  the  operation  of  the 
system's  security. 


2.1.4  Documentation 

Documentation  is  an  important  part  of  the  software  development  process.  It 
aids  users  who  are  not  familiar  with  the  system  in  learning  how  to  use  the 
system  correctly.  It  aids  support  programmers  in  testing  the  system  to 
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ensure  that  a  modification  has  not  had  a  negative  impact  on  the  system. 
This  is  especially  important  when  developing  a  TCB,  because  the  security  of 
the  system  is  of  the  utmost  importance.  While  this  is  true,  no  special 
consideration  needs  to  be  given  to  the  development  of  the  documentation  for 
a  TCB.  The  documentation  must  be  developed  to  meet  all  requirements  set 
forth  in  the  TCSEC  and  must  be  complete  and  up-to-date;  however,  this  is  not 
particular  to  this  development  and  requires  no  further  discussion. 

2. 1.4.1  Security  Features  User's  Guide 

o  Single  summary,  chapter.  or  manual  in  user  documeaitaticn  shall  describe 
the  protection  mechanisms  provided  by  the  TCB.  guidelines  can  their  use, 
and  how  they  interact  with  one  another 


2. 1.4. 2  Trusted  Facility  Manual 

o  Mara ra  1  addressed  to  the  ADP  system  administrator  shall  present  cautions 

about  functions  and  privileges  that  should  be  controlled  when  running  a 
secure  facility 

2. 1.4.3  Test  Documentation 

o  System  developer  shall  provide  to  the  evaluators  a  document  that 
describes  the  test  plan,  test  procedures  that  shew  how  the  security 
mechanisms  hb»»  tested,  and  results  of  the  security  mechanicair:1 
functional  testing 

2. 1.4. 4  Design  Documentation 

o  Documentation  shall  be  available  that  provides  a  description  of  the 
manufacturer's  philosophy  of  protection  and  an  explanation  of  how  this 
philosophy  is  translated  into  the  TCB 

If  the  TCB  is  oamosed  of  distinct  modules,  the  interfaces  between 
these  modules  shall  be  described 


A-15 


APPENDIX  A 
Division  C,  Class  C2 


2.2  CLASS  C2:  OCNTROIIED  ACCESS  LROTECTICN 

"Systems  in  this  class  enforce  a  more  finely  grained  discretionary  access  control 
than  Cl  systems,  making  users  individually  accountable  for  their  actions  through 
login  procedures,  auditing  of  security-relevant  events,  and  resource  isolation." 

2.2.1  Security  Policy 

2.2. 1.1  Discretionary  Access  Ccntrol 

(Cl) : 

o  TCB  shall  define  and  control  access  between  named  users  and  named 
objects  in  the  ADP  system 

o  Enforcement  mechanism  shall  allow  users  to  specify  and  control  sharing 
of  those  objects  by  named  individuals  or  defined  groups  of  individuals, 
or  by  both,  and  shall  provide  controls  to  limit  propagation  of  access 
rights 

o  Disoneticnarv  aooess  control  mechanism  shall,  either  by  explicit  user 
action  or  default,  provide  that  objects  are  protected  from  unauthorized 
aooess 

o  Access  controls  shall  be  capable  of  including  nr  excluding  aocess  to 
the  granularity  of  a  single  user 

o  Aooess  permission  to  an  object  by  users  not  already  possessing  access 
permission  shall  only  be  assigned  by  authorized  users 

Requirements: 

(Cl)  : 


Identify  all  types  of  users  for  the  system,  including  individual  users 
and  groups  of  users 

Identify  all  types  of  objects  (e.g.,  files  and  programs)  in  the  system 
Identify  the  level  of  sensitivity  for  the  data  within  the  system 
Describe  all  possible  interactions  between  the  users  and  the  data 
Identify  the  criteria  for  determining  the  need  of  a  particular  user  to 
access  a  particular  object 

Identify  specific  individuals  to  be  included  in  each  group  of  users 


As  can  be  seen  in  the  description  of  a  Class  C2  TCB,  this  class  requires  a 
more  finely  grained  discretionary  access  control  than  the  Class  Cl.  This 
degree  of  granularity  is  enforced  by  requiring  that  specific  individuals 
must  be  included  in  a  group  and  then  identified  during  the  requirements 
phase  of  the  software  development.  In  Class  C2,  the  individual  is 
accountable  for  his  cwn  actions  even  though  he  may  be  operating  as  a  member 
of  a  group;  therefore,  it  is  still  important  to  be  able  to  identify  the 
individual. 
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Design: 

(Cl): 


Establish  a  method  for  maintaining  the  enforcement  mechanism  (e.g. , 
self/group/public  controls,  access  control  lists) 

Establish  a  method  of  controlling  access  to  objects  within  the  domain 
of  the  TCB 

Establish  criteria  for  determining  the  need  of  a  particular  user  to 

access  a  particular  object 

Establish  a  mechanism  for  identifying  users 

Coding: 

(Cl): 


Use  a  defensive  programming  methodology,  including  hooks,  to  aid 
testing  and  maintenance 

Support: 

(Cl): 


Re-test  system  upon  completion  of  modification 

Ensure  that  enforcement  mechanism  access  control  lists  are  maintained, 
e.g. ,  adding  new  users  to  the  access  control  lists  and  removing  users 
from  the  access  control  lists  who  no  longer  require  access  to  the 
system 


2.2. 1.2  Object  Reuse 

o  TCB  shall  assure  that  when  a  storage  object  is  initially  assigned, 
allocated,  or  reallocated  to  a  subject  from  the  TCB's  pool  of  unused 
storage  objects,  the  object  contains  no  data  for  which  the  subject  is 
not  authorized 


Requirements: 


Identify  all  situatiuns  hi  which  a  stoiaue  obleut  is  iiiiLiully 
assigned,  allocated,  or  reallocated  from  the  TCB's  pool  of  unused 
storage  objects 

Identify  methnrte  for  removing  data  from  objects 


A-17 


APPENDIX  A 
Division  C,  Class  C2 


Various  types  of  storage  objects  controlled  by  a  Class  C2  TCB  are  subject  to 
being  reused;  therefore,  they  need  to  be  identified  and  the  situations  that 
would  result  in  their  reuse  need  to  be  identified.  These  situations  include 
the  initial  assignment  to,  allocation  to,  and  reallocation  from  the  TCB's 
pool  of  unused  storage  objects. 

In  addition  to  identifying  all  situations  in  which  an  object  could 
potentially  be  reused,  the  various  methods  for  removing  unauthorized  data 
from  those  objects  need  to  be  identified.  Once  the  possible  methods  for  the 
removal  of  data  have  been  identified,  they  can  be  evaluated  against  the 
other  system  requirements,  such  as  those  for  system  performance.  In  this 
manner,  the  best  data  removal  method  can  be  chosen  and  implemented  during 
the  design  phase. 

Design: 

-  Establish  a  method  for  determining  authorization  of  subject  for  object 

-  Establish  a  method  for  removing  data  for  which  subject  is  not 
authorized 

A  mechanism  for  managing  storage  object  reuse  must  be  established.  Its 
design  must  satisfy  the  requirements  stated  above,  allow  the  determination 
of  authorization  of  subjects  for  objects,  and  facilitate  the  removal  of 
unauthorized  data. 


2.2.2  Accountability 

2.2.2. 1  Identification  and  Authentication 
(Cl): 

o  TCB  shall  require  users  to  identify  themselves  to  it  before  beginning 
to  perform  any  other  actions  that  the  TCB  is  expected  to  mediate 
o  TCB  shall  use  a  protected  mechanism  to  authenticate  the  user's  identity 
o  TCB  shall  protect  authentication  data  so  that  ir  cannot  be  accessed  by 
any  unauthorized  user 

o  TCB  shall  be  able  to  enforce  individual  accountability  by  providing  the 
capability  to  uniquely  identify  each  individual  ADP  system  user 
o  TCB  shall  provide  the  capability  of  associating  the  individual  identity 
with  all  m VH table  actions  taken  by  that  individual 
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Requirements: 

(Cl): 


Identify  all  actions  to  be  mediated  by  the  TCB,  including  access  to 
authentication  data 

Define  a  standard  format  for  authentication  data 
Determine  a  method  for  identifying  users 


Design: 

(Cl): 


Establish  a  mechanism  for  identifying  and  authenticating  users 
Establish  a  mechanism  for  creating  and  maintaining  authentication  data 
-  Establish  a  mechanism  for  associating  user  identity  with  user  actions 

Under  Class  Cl,  the  user  must  identify  himself  to  the  TCB  prior  to  being 
allowed  to  access  any  actions  mediated  by  it.  This  requirement  is  enforced 
in  a  C2  TCB,  with  the  additional  stipulation  that  all  auditable  actions 
performed  by  that  user  can  be  associated  with  that  user.  To  accomplish 
this,  some  type  of  mechanism  for  associating  the  user's  identity  with  the 
actions  taken  by  that  user  must  be  available.  To  do  this,  during  the  design 
phase  of  Identification  and  Authentication,  the  mechanism  will  need  to  be 
detailed.  As  an  example,  the  method  chosen  to  identify  the  user  could  be  to 
require  him  to  enter  his  Social  Security  Number  (SSN) .  The  mechanism  for 
associating  the  user  identity  with  the  user  actions  could  create  files 
containing  SSN  and  actions  for  each  auditable  function  mediated  by  the  TCB. 
These  files  could  be  examined  at  a  later  time  to  check  to  see  that  all 
accesses  to  that  function  were  performed  in  good  faith  and  that  no  user 
accidentally  read,  modified,  or  deleted  information  which  should  not  have 
been  read,  modified,  or  deleted  by  that  user. 


2. 2. 2. 2  Ardit 


o 


o 

o 


TCB  shall  be  able  to  create,  maintain,  and  protect  frtjn  codification  or 
unauthorized  access  or  destruction  an  audi  t  trail  of  accesses  to  the 
objects  it  protects 

Audit  data  shall  be  protected  by  the  TCB  so  that  read  access  to  it  is 
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TCB  bp,  able  to  record:  usp.  of  i identification  and  authentication 


mechanisms,  introdirticn  of  objects  into  a  user's  address  space, 
deletion  of  objects,  actions  taken  by  canxtter  operators  and  system 
administrators  and/or  system  security  officers,  and  other  security 


relevant  events. 
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o  For  each  recorded  event,  the  audit  record  shall  identify:  date  and 
time  of  the  event,  user,  type  of  event,  and  success  or  failure  of  the 
event.  For  identification  and  authentication  events,  the  audit  rprard 
shall  include  origin  of  request  r terminal  TP) .  For  events  that 

introduce  an  object  into  a  u yr's  address:  spaoe  and  for  object  deletion 
events,  the  audit  -record  shall  include  the  name  nf  the  object, 
o  MTP  system  admini-strator  shall  be  able  to  selectively  audit  the  actions 
of  any  one  or  more  users  based  on  individual  identity 


Requirements: 

-  Identify  all  objects  to  be  protected  by  the  TCB 

-  Determine  complete  reguirgrents  for  Audit  Function 

To  correctly  determine  the  requirements  for  Class  C2  TCB  auditing  functions, 
all  objects  that  need  to  be  protected  by  the  TCB  must  be  identified,  and  the 
means  for  auditing  them  must  be  determined.  The  use  of  identification  and 
authentication  data  and  the  introduction  of  objects  into  a  user's  address 
space  must  be  included.  Hie  following  items  must  be  monitored  in  order  to 
audit  each  recorded  event:  the  date  and  time  of  the  event,  user,  type  of 
event,  and  success  or  failure  of  the  event. 

Design: 

-  Establish  a  mechanic  for  operation  of  the  Audit  Function 

The  design  of  the  auditing  functions  of  a  Class  C2  TCB  must  satisfy  the 
requirements  stated  above.  To  accomplish  this,  the  design  must  include  a 
mechanism  for  the  operation  of  the  audit  functions.  The  audit  record  should 
be  maintained  on-line,  and  it  shouJd  also  be  able  to  be  output  in  a  human- 
readable  form. 


2.2.3  Assurance 

2. 2. 3.1  Operational  Assurance 
2. 2. 3. 1.1  System  Architecture 


(Cl): 

o  TCB  shall  maintain  a  domain  for  its  own  execution  that  protects  it  from 
external  interference  or  tampering 

o  Resources  controlled  by  the  TCB  may  be  a  defined  subset  of  the  subjects 
and  objects  in  the  ADP  system 


APPENDIX  A 
Division  C,  Class  C2 


o  TCB  shall  isolate  the  resources  to  be  protected  so  that  they  are 
subject  to  the  access  control  and  auditing  rprrtnrrw>nts 

Requirements: 

(Cl): 


Identify  all  resources  to  be  protected  by’  the  TCB,  including  the  TCB 
code  and  data  structures 


Design: 
(Cl) : 


Establish  a  mode  for  protecting  each  resource  within  the  TCB 
~  Establish  a  method  of  isolating  resources  to  be  protected  bv  the  TCB 

The  design  of  the  system  architecture  of  a  Class  C2  TCB  must  satisfy  the 
requirement  stated  above.  In  addition,  the  design  must  include  a  method  for 
isolating  resources  to  be  protected  by  the  TCB.  The  method  may  use  a 
iiiechanism  such  as  passwords  for  individuals  or  groups  of  individuals  to 
further  ensure  the  security  of  the  resources  by  having  their  access 
controlled  and  audited.  Thus,  it  provides  additional  protection  of  the 
resources  from  being  accessed  by  unauthorized  subjects. 


2. 2. 3. 1.2  System  Integrity 


(Cl): 

o  Hardware  and/or  software  features  shall  be  provided  that  can  be  used  to 
periodically  validate  the  correct  operation  of  the  on-site  hardware  and 
firmware  elements  of  the  TCB 

Requirements: 

(Cl): 


Identify  hardware  and  firmware  elements  of  the  TCB  to  be  validated 
Determine  validation  criteria  for  testing  each  element  cf  the  TCB 


Determine  the  appropriate  interval  at  which  validation  of 
hardware/ firmware  should  take  place 


the 
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Design: 

(Cl): 


Establish  a  method  for  testing  each  criterion  for  each  element  of  the 
TCB 

2 . 2 . 3 . 2  life-cycle  Assurance 
2. 2-3. 2.1  Security  Testing 


(Cl): 

o  Security  mechanisms  of  the  ADP  system  shall  be  tested  and  found  to  work 
as  claimed  in  the  system  documentation 

o  Testing  shall  be  done  to  assure  that  there  are  no  obvious  ways  for  an 
unauthorized  user  to  bypass  or  otherwise  defeat  the  security  protection 
mechanisms  of  the  TCB 

o  Testing  shall  include  a  search  for  obvious  flaws  that  would  allow 
violation  of  resource  isolation  or  that  wculd  permit  unauthorized 
access  to  audit  or  authentication  data 

Requirements: 

(Cl): 


Identify  security  protection  mechanisms  of  the  TCB  to  be  tested 
Design: 

(Cl): 


Establish  a  means  of  testing  each  security  protection  mechanism 

Coding: 

(Cl): 


Use  prudently  placed  debug  statements  to  allcw  the  tester  to  monitor 
operation  of  the  security  mechanisms 
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2.2.4  Documentation 
(Cl): 

Documentation  is  an  important  part  of  the  software  development  process.  It 
aicL;  users  who  are  not  familiar  with  the  system  in  learning  hew  to  use  the 
system  correctly.  It  aids  support  programmers  in  testing  the  system  to 
ensure  that  a  modification  has  not  had  a  negative  inpact  on  the  system. 
This  is  especially  important  when  developing  a  TCB.  because  the  security  of 
the  system  is  of  the  utmost  importance.  While  this  is  true,  no  special 
consideration  needs  to  be  given  to  the  development  of  the  documentation  for 
a  TCB.  The  documentation  must  be  developed  to  meet  all  requirements  set 
forth  in  the  TCSEC,  and  must  be  complete  and  up-to-date;  however,  this  is 
not  particular  to  this  development  and  requires  no  further  discussion. 

2. 2. 4.1  Security  Features  User's  Guide 
(Cl): 

o  Single  summary,  chapter,  or  manual  in  user  documentation  shall  describe 
the  protection  mechanisms  provided  by  the  TCB,  guidelines  on  their  use, 
and  how  they  interact  with  one  another 

2. 2. 4. 2  Trusted  Facility  Manual 
(Cl): 


o  Manual  addressed  to  the  ADP  system  administrator  shall  present  cautions 
about  functions  and  privileges  that  should  be  controlled  when  running  a 
secure  facility. 

o  The  procedures  for  examining  and  maintaining  the  audit  files,  as  well 
as  the  detailed  audit  record  structure  for  each  type  of  audit  event, 
shall  be  given. 

2. 2. 4. 3  Test  Documentation 


(Cl): 


o 


System  developer  shall  provide  to  the  evaluators  a  document  that 
describes  the  test  plan,  test  procedures  that  show  how  the  security 
mechanisms  were  tested,  and  results  of  the  security  mechanisms' 
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2. 2. 4. 4  Design  Documentation 


(Cl): 

o  Documentation  shall  be  available  that  provides  a  description  of  the 
manufacturer's  philosophy  of  protection  and  an  explanation  of  hew  this 
philosophy  is  translated  into  the  TCB 

o  If  the  TCB  is  canposed  of  distinct  modules,  the  interfaces  between 
these  modules  shall  be  described 
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3.0  DIVISION  B:  MANDATORY  PROTECTION 


3.1  CLASS  Bl:  LABELED  SECURITY  PROTECTION 

"Class  Bl  systems  require  all  the  features  required  for  Class  C2.  In  addition, 
an  informal  statement  of  the  security  policy  model,  data  labeling,  and  mandatory 
access  control  over  named  subjects  ard  objects  must  be  present.  The  capability 
must  exist  for  accurately  labeling  exported  information.  Any  flaws  identified  by 
testing  must  be  removed." 

3.1.1  Security  Policy 

3. 1.1.1  Discretionary  Access  Control 

(Cl): 

o  TCB  shall  define  and  control  access  between  named  users  and  named 
objects  in  the  ADP  system 

o  Enforcement  mechanism  shall  allow  users  to  specify  and  control  sharing 
of  those  objects  by  named  individuals  or  defined  groups  of  individuals, 
or  both,  and  shall  provide  controls  to  limit  propagation  of  access 
rights. 

(C2) : 

o  Discretionary  access  control  mechanism  shall,  either  by  explicit  user 
action  or  default,  provide  that  objects  are  protected  from  unauthorized 
access 

o  Access  controls  shall  be  capable  of  including  or  excluding  access  to 
the  granularity  of  a  single  user 

o  Access  permission  to  an  object  by  users  not  already  possessing  access 
permission  shall  only  be  assigned  by  authorized  users 

Requirements: 

(Cl): 

Identify  all  types  of  users  for  the  system,  including  individual  users 
and  groups  of  users 

Identify  all  types  of  objects  (e.g. ,  files  and  programs)  in  the  system 
Identify  the  level  of  sensitivity  fur  the  data  within  the  system 
Describe  all  possible  interactions  between  the  users  and  the  data 
Identify  the  criteria  for  determining  the  need  of  a  particular  user  to 
access  a  particular  object 
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(C2) : 


Identify  specific  individuals  to  be  included  in  each  group  of  users 
Design: 

(Cl): 


Establish  a  method  for  maintaining  the  enforcement  mechanism  (e.g., 
self/group/public  controls,  access  control  lists) 

Establish  a  method  of  controlling  access  to  objects  within  the  domain 
of  the  TCB 

Establish  criteria  for  determining  the  need  of  a  particular  user  to 

access  a  particular  abject 

Establish  a  mechanism  for  identifying  users 

Coding: 

(Cl): 


Use  a  defensive  programming  methodology,  including  hooks,  to  aid 
testing  and  maintenance 

Support: 

(Cl): 


Re-test  system  upon  completion  of  modification 

Ensure  that  enforcement  mechanism  access  control  lists  are  maintained, 
e.g.,  adding  new  users  to  the  access  control  lists  and  removing  users 
from  the  access  control  lists  who  no  longer  require  access  to  the 
system 


3. 1.1. 2  Object  Reuse 
(C2) : 

o  TCB  shall  ensure  that  when  a  storage  object  is  initially  assigned, 

allocated,  or  reallocated  to  a  subject  from  the  TCB's  pool  of  unused 

storage  objects,  the  object  contains  no  data  for  which  the  subject  is 

|  _ ! 
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Requirements: 
(C2) : 


Identify  all  situations  in  which  a  storage  object  is  initially 
assigned,  allocated,  or  reallocated  from  the  TCB's  pool  of  unused 
storage  objects 

Identify  methods  for  removing  data  from  objects 
Design: 

(C2) : 

Establish  a  method  for  determining  authorization  of  subject  for  object 
Establish  a  method  for  removing  data  for  which  subject  is  not 
authorized 


3.1. 1.3  Labels 

o  Sensitivity  labels  associated  with  each  subject  and  storage  object 
under  its  control  shall  be  maintained  by  the  TCB 

o  These  labels  shall  be  used  as  the  basis  for  mandatory  access  control 
decisions 

o  To  import  non-labeled  data,  the  TCB  shall  request  and  receive  from  an 
authorized  user  the  security  level  of  the  data,  and  all  such  actions 
shall  be  auditable  by  the  TCB 

Requirements: 


Identify  all  subjects  and  storage  objects  under  the  control  of  the  TCB 
Define  a  policy  for  associating  sensitivity  labels  with  each  subject 
and  storage  object  controlled  by  the  TCB.  including  the  irmort  of  non- 
labeled  data  and  the  export  of  labeled  data 


Sensitivity  labels,  as  required  for  a  Class  B1  TCB,  must  be  associated  with 
each  subject  and  storage  object  under  control  of  the  TCB.  The  labels  shall 
be  used  as  the  basis  for  access  control  decisions;  therefore,  the  subjects 
and  storage  objects  requiring  sensitivity  labels  must  be  identified,  and  a 
policy  must  be  defined  for  associating  the  labels  with  each  subject  and 
storage  object.  This  includes  the  importing  of  non-labeled  data  and  the 
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and  protected  by  the  TCB  are  personnel  records  and  inventory  data. 
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Design: 

-  Establish  a  mecbarnCTi  for  iTipIprnprrh'inq  and  managing  the  sensitivity 
labels 

-  Establish  an  interactlcn  between  sensitivity  labeling  and  the  audit 
function 

-  Establish  a  mechanism  for  changing  and  aonitorim  the  sensitivity 
designation 

The  design  of  the  mechanism  to  handle  sensitivity  labels  must  satisfy  the 
requirements  stated  above.  To  accomplish  this  it  must  have  a  means  for 
implementing  and  managing  the  sensitivity  labels.  This  involves  handling 
the  interactions  between  the  sensitivity  labeling  and  the  audit  functions. 
Also,  the  design  requires  a  mechanism  for  changing  and  monitoring  the 
sensitivity  designation.  The  labels  may  be  in  the  form  of  designators,  such 
as  distribution  restrictors  or  enablers,  for  controlling  access  by 
individuals  or  groups  of  users  and/or  access  type  restrictors  that  limit  the 
type  of  access  permitted  to  an  object.  This  provides  the  TCB  with  a  means 
of  maintaining  the  integrity  of  the  security  label  information. 


3. 1.1. 3.1  label  Integrity 

o  Sensitivity  labels  shall  accurately  reflect  security  levels  of  the 
specific  subjects  or  objects  with  which  they  are  associated 
o  Sensitivity  labels  shall  accurately  reflect  the  internal  labels  and 
shall  be  associated  with  exported  information 

Requirements: 

Identify  the  data  required  for  sensitivity  labels  to  represent, 
accurately  and  unambiguously,  security  levels  of  specific  subjects  or 
objects  with  which  they  are  associated 

Ensuring  the  integrity  of  the  sensitivity  labels  requires  the  identification 
of  the  data  needed  to  accurately  and  unambiguously  represent  security  levels 
of  specific  subjects  or  objects  with  which  they  are  associated.  An  analysis 
must  be  done  to  determine  this  data's  critical  characteristics  that  satisfy 
this  criteria.  Seme  typical  characteristics  are  the  security  level 
associated  with  the  subjects  and  objects,  the  group  of  users  to  be  allowed 
access  to  objects,  and  restrictions  on  the  mode  of  accessing  an  object 
(e.g. ,  read  access  cnxy,  wifiue  access,  privilege  to  purge,  and  monitor 
history  of  accesses) . 
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Design: 

Establish  an  association  between  sensitivity  labels  exported  by  the  TCB 
and  the  informaticn  being  exported  r  «=airh  that  the  sensitivity  labels 
accurately  and  unambiguously  represent  security  levels  of  specific 
subjects  car  objects  with  which  they  are  associated. 


The  design  of  the  mechanism  for  maintaining  the  label  integrity  must  satisfy 
the  requirements  stated  above.  Thus,  it  must  include  an  accurate  and 
unambiguous  association  between  the  sensitivity  labels  and  the  security 
levels  of  specific  subjects  or  objects.  This  association  must  provide  a 
secure  and  reliable  logical  connection  between  the  label  and  its  associated 
subject  or  abject. 


3. 1.1. 3. 2  Exportation  of  labeled  Information 

o  TCB  shall  designate  each  ccummi cation  channel  and  I/O  device  as  either 


single-level  or  multilevel ;  any  change  in  this  designation  shall  be 
done  manually  and  shall  he  auditable  by  the  TCB 

o  TCB  shall  maintain  and  be  able  to  audit:  any  change  in  the  current 
security  level  associated  with  a  single  crnmunication  channel  or  I/O 
device 

o  When  TCB  exports  an  object  to  a  multilevel  I/O  device,  the  sensitivity 
label  associated  with  that  object  shall  also  be  exported  and  shall 
reside  on  the  same  physical  medium  as  the  exported  information  and 
shall  he  in  the  same  form 

o  Export  or  import  protocol  used  an  a  multilevel  omnmnnication  channel 
shal  1  provide  for  the  urairbiauous  pairing  befcwaen  the  sensitivity 
labels  and  the  associated  information 

o  Single-level  I/O  devices  and  single-level  ccmnunicaticn  channels  are 


not  required  to  maintain  the  sensitivity  labels  of  the  information 


recess;  however,  the  TCB  shall  include  a  mechanism 


and  an  authorizes  user  reliably  cauamicate  to  desi 


security  level  of  imported  or  exported  informaticn 


ADP  system  administrator  shall  be  able  to 


associated  with  exported  sensitivity  labels 


beg 

innir 

d 

and  end  of  all  human-readable. 

human-readable  sensitivi 


and  bottom  of  each 


of  human- 


default,  marie  other  forms  of  human-readable 


human-readable  sensitivi 


resent  the 


sensitivity  of  the  output 

o  TCB  shall  audit  ary  override  of  these  marking  defaults 
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Requirements: 

-  TrterrHfv  the  tvp e«  <~>f  rrrramicatian  channels  and  I/O  devices  to  be  used 
with  the  TCB  arri  whether  they  are  single-level  or  mil ti level  devices 
Define  the  policy  for  establ  i  i  m/chanaina  the  security  designation 
associated  with  these  devices 

-  Define  the  policy  for  handling  the  preparation  and  handling  of  human- 
readable  outmt.  including  its  fora 

A  means  must  be  provided  for  the  exportation  of  labeled  information.  This 
requires  the  identification  of  the  types  of  communication  channels  and  I/O 
devices  to  be  used  with  the  TCB,  including  whether  they  are  single-level  or 
multilevel  devices.  Ensuring  the  proper  management  of  this  process  requires 
the  definition  of  the  policy  for  establishing/changing  the  security 
designation  associated  with  these  devices.  Also,  a  policy  must  be  defined 
for  the  preparation  and  handling  of  human-readable  output.  These 
requirements  promote  secure  and  reliable  transfer  of  labeled  information 
through  communication  channels  and  between  I/O  devices. 

Design: 

Establish  tte  protocol  for  inrortincr  and  exporting  objects  between  the 
TCB  and  secure  single-level  or  multilevel  devices 

-  Establish  the  mpchanism  fnr  labeling  and  producing  human-readable 
output 

The  design  of  mechanisms  for  handling  the  exportation  of  labeled  information 
must  satisfy  the  requirements  stated  above.  To  accomplish  this  a  protocol 
must  be  established  for  importing  and  exporting  objects  between  the  TCB  and 
secure  single-level  or  multilevel  devices.  Also  for  human-readable  output 
(e.c.,  printed  output  and  information  displayed  on  a  terminal),  the  design 
must  include  mechanisms  for  labeling  and  producing  the  output. 

3. 1.1. 4  Mandatory  Access  Ccntrol 

o  TCB  shall  enforce  a  mandatory  aooess  ccntrol  policy  over  all  subjects 
and  storage  objects  under  its  control 

o  All  subjects  and  storage  objects  shall  be  assigned  sensitivity  labels 
that  are  a  ccnfcinaticn  of  hierarchical  classification  levels  and  nan- 
hierarchical  categories ,  and  the  labels  shall  be  the  basis  of  the 
mandatory  access  control  decisicns 
o  TCB  shall  be  able  to  support  two  or  more  security  levels 
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Requirements: 

-  Identify  all  subjects  and  storage  objects  under  the  cxrrtrol  of  the  TCB 

-  Describe  the  hierarchical  clarification  levels  and  ncrt-Merarchical 
categories  vithin  the  TCB 

-  Define  the  mandatory  access  rratrol  Policy  based  upon  the 
clar  i  f  i  rati  cn  Iwpjs  vithin  the  TCB 

To  accurately  define  the  requirements  of  the  mandatory  access  control  for  a 
Class  B1  TCB,  all  subjects  and  storage  objects  that  are  to  be  under  the 
control  of  the  TCB  must  first  be  identified.  Then  the  hierarchical 
classification  levels  and  non-hierarchical  categories,  which  are  to  be 
associated  with  these  subjects  and  objects  within  the  TCB,  need  to  be 
described.  A  policy  for  the  mandatory  access  control  must  be  defined  that 
is  based  on  these  classification  levels  and  categories.  This  policy  will 
establish  secure  practices  for  subjects  to  access  objects  (e.g. ,  read, 
write,  and  modify)  for  which  they  have  sufficient  clearance. 

Design: 

“  Establish  a  mechanism  far  implementing  the  mandatory  access  control 
policy 

The  design  of  the  mandatory  access  control  must  satisfy  the  requirements  for 
a  Class  B1  TCB,  as  seated  above.  Thus,  a  mechanism  must  be  established  for 
implementing  the  mandatory  access  control  policy.  In  particular,  monitoring 
of  subjects  attempting  to  access  objects  needs  to  be  performed  such  that  the 
following  hold  for  all  accesses  Detween  subjects  and  objects  controlled  by 
the  TCB:  a  subject  may  read  an  object  only  if  its  security  level  is  great 
enough  to  access  the  object,  as  determined  by  comparison  with  the  object's 
security  level;  subject  may  write  or  modify  an  object  only  if  its  security 
level  is  low  enough  to  access  the  object,  as  determined  by  comparison  with 
the  object's  security  level.  For  further  elaboration  on  mandatory'  access 
control,  refer  to  the  TCSEC. 


3.1.2  Accountability 
3. 1.2.1  Identification  and  Authentication 


(Cl): 

o  TCB  shall  require  users  to  identify  themselves  to  it  before  beginning 
to  perform  any  other  actions  that  the  TCB  is  expected  to  mediate 
o  TCB  shall  maintain  authentication  data  that  includes  information  for 
verifying  the  identity  of  individual  users  as  well  as  information  for 
determining  t.je  clearance  and  authorizations  of  individual  users 
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o  TCB  shall  use  this  data  to  authenticate  the  user's  identity  and  to 
determine  the  security  level  and  authorizations  of  subjects  that  may  be 
created  to  act  on  the  behalf  of  the  individual  user 
o  TCB  shall  protect  authentication  data  so  that  it  cannot  be  accessed  by 
any  unauthorized  user 


(C2) : 

TCB  shall  be  able  to  enforce  individual  accountability  by  providing  the 
capability  to  uniquely  identify  each  individual  ADP  system  user 
TCB  shall  provide  the  capability  of  associating  the  individual  identity 
with  all  auditable  actions  taken  by  that  individual 

Requirements: 

(Cl): 


Identify  all  actions  to  be  mediated  by  the  TCB,  including  access  to 
authentication  data 

Define  a  standard  format  for  authentication  data 
Determine  a  method  for  identifying  users 

Design: 

(Cl): 

Establish  a  mechanism  for  identification  and  authentication  of  users 
Establish  a  mechanism  for  creating  and  maintaining  authentication  data 

(C2) : 

Establish  a  mechanism  for  associating  user  identity  with  user  actions 


3. 1.2. 2  Audit 


(C2) : 

o  TCB  shall  be  able  to  create,  maintain,  and  protect  from  modification  or 
unauthorized  access  or  destruction  an  audit  trail  of  accesses  to  the 
objects  it  protects 

c  Audit  data  shall  be  protected  by  the  TCB  so  that  read  access  to  it  is 
limited  to  those  who  are  authorized  for  audit  data 
o  TCB  shall  be  able  to  record:  use  of  identification  and  authentication 
mechanisms,  introduction  of  objects  into  a  user's  address  space, 
deletion  of  objects,  actions  taken  by  computer  operators  and  system 
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administrators  and/or  system  security  officers,  and  other  security 
relevant  events. 

o  TCB  shall  hp  aKI^  to  audit  any  override  of  human-readable  output 
markings. 

o  For  each  recorded  event,  the  audit  record  shall  identify:  date  and  time 
of  event,  user,  type  of  event,  and  success  or  failure  of  the  event.  For 
identification  and  authentication  events,  the  audit  record  shall 
include  origin  of  request  (terminal  ID) .  For  events  that  introduce  an 
object  into  a  user's  address  space  and  for  object  deletion  events,  the 
audit  record  shall  include  the  name  of  the  object  and  the  object's 
security  level. 

o  ADP  system  administrator  shall  be  able  to  selectively  audit  the  actions 
of  any  one  or  more  users  based  on  individual  identity  and/or  object 
security  level. 

Requirements: 

(C2) : 


Identify  all  objects  to  be  protected  by  the  TCB 
Establish  complete  requirements  for  Audit  Function 

Design: 

(C2) : 

Establish  a  mechanism  for  operation  of  the  Audit  Function 


3.1.3  Assurance 

3. 1.3.1  Operational  Assurance 
3. 1.3. 1.1  System  Architecture 


(Cl): 

c  TCB  shall  maintain  a  domain  for  its  cwn  execution  that  protects  it  from 
external  interference  or  tampering 

o  Resources  controlled  by  the  TCB  may  be  a  defined  subset  of  the  subjects 
and  objects  in  the  ADP  system 

ri  nvna  woi rrf-a i nvrsnocc  i crvl  af  ■? rtn  4*Vvrr«vih  fKo  nmtricinn  of  Hicfirv’t' 
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address  spaces  under  its  control 
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(C2) : 

o  TCB  shall  isolate  the  resources  to  be  protected  so  that 

they  are  subject  to  the  access  control  and  auditing  requirements 


Requirements: 

(Cl }  : 


Identify  all  resources  and  distintTh  oldness  spaces  to  be  protected  by 
the  TCB,  including  the  TCB  code  and  data  structures 

With  one  exception,  the  requirements  for  a  Class  B1  TCB  will  be  developed  in 
a  manner  that  is  essentially  the  same  as  that  for  the  previous  classes  of 
TCBs.  In  a  Class  B1  TCB,  the  isolation  of  processes  maintained  by  the  TCB 
will  be  accomplished  through  the  use  of  distinct  address  spaces  to  be 
controlled  by  the  TCB.  As  a  result  of  this  exception,  the  requirements  for 
this  TCB  will  need  to  identify  the  address  spaces  to  be  used  for  this 
isolation.  This  identification  is  necessary  so  that  the  system  developer 
can  determine,  during  the  design  phase,  the  best  way  to  protect  the  address 
space  and  its  associated  processes. 

Design: 

(Cl): 


Establish  a  mode  for  protecting  each  resource  and  each  distinct  address 
space  within  the  TCB 


(C2): 


Establish  a  method  of  isolating  resources  to  be  protected  by  the  TCB 

As  mentioned  in  the  System  Architecture  Requirements,  once  the  address 
spaces  to  be  protected  by  the  TCB  have  been  identified,  it  is  necessary  for 
the  system  developer  to  establish  a  mode  for  protecting  each  of  them.  This 
protection  scheme  may  include  hardware,  firmware,  or  software,  or  same 
combination  of  all  three.  Whatever  the  case,  the  intended  use  of  the  item 
to  be  protected  needs  to  be  determined  so  that  the  most  reliable  protection 
scheme  is  utilized. 


A-34 


APPENDIX  A 
Division  £,  Class  Bi 


3 . 1 . 2 . 1 . 2  System  Integrity 


(Cl): 

o  Hardware  and/or  software  features  shall  be  provided  that  can  be  used  to 
periodically  validate  the  correct  operation  of  the  on-site  hardware  and 
firmware  elements  of  the  TCB 

Requirements: 

(Cl) : 


Identify  hardware  and  firmware  elements  of  the  TCB  to  be  validated 
Determine  validation  criteria  for  testing  each  element  of  the  TCB 
Determine  the  appropriate  interval  at  which  validation  of  the 
hardware/firmware  should  take  place 

Design: 

(Cl): 


Establish  a  method  for  testing  each  criterion  for  each  element  of  the 
TCB 

3. 1.3. 2  Iafe-Cycle  Assurance 
3. 1.3. 2.1  Security  Testing 


(Cl): 

o  Security  mechanisms  of  the  ADP  system  shall  be  tested  and  found  to  work 
as  claimed  in  the  system  documentation 

o  Team  of  individuals  who  thoroughly  understand  the  specific 
inplementation  of  the  TCB  shall  subject  its  design  documentation, 
source  code,  and  object  code  to  thorough  analysis  and  testing.  The 
team's  objectives  will  be  to  uncover  all  design  and  implementation 
flaws  that  would  permit  a  subject  external  to  the  TCB  to  read,  change, 
or  delete  data  normally  denied  under  the  mandatory  or  discretionary 
security  policy,  and  to  assure  that  no  subject  is  able  to  cause  the  TCB 
to  enter  a  state  such  that  it  is  unable  to  respond  to  camainications 

gfKor  ncorc 

o  All  dif=covered  flaws  shall  h p.  removed  or  neutralized  and  the  TCB 
retested  to  d<*mnstrate  that  they  have  been  el-i-minat-pd  and  that  new 
flaws  have  not  been  introduced 
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Requirements: 

(Cl): 


Identify  security  protection  mechanisms  of  the  TCB  to  be  tested 


Design: 

(Cl): 


Establish  a  means  of  testing  each  security  protection  mechanism  in  a 
manner  consistent  with  the  stringent  retirements  detailed  in  the  TCSEC 

Although  the  design  of  the  Security  Testing  aspect  of  a  Class  Bl  TCB  is  not 
really  different  from  that  of  any  of  the  previous  classes,  the  requirements 
set  forth  for  it  in  the  TCSEC  are  much  more  detailed.  As  such,  more 
attention  needs  to  be  paid  to  determining  the  means  for  testing  each 
security  protection  mechanism.  The  design  for  this  security  testing  needs 
to  be  performed  in  strict  accordance  with  the  requirements  of  the  TCSEC. 

Coding: 

(Cl): 


Use  prudently  placed  debug  statements  to  allow  the  tester  to  monitor 
operation  of  the  security  mechanisms 


3. 1.3. 2. 2  Design  Specification  and  Verification 

°  Informal  or  formal  mrrig>1  of  the  security  policy  supported  by  the  TCB 
shall  he  maintained  that  is  shown  to  be  consistent  with  its  axioms. 

Design: 

Identify  the  model  to  be  vised 
-  Establish  consistency  between  design  and  the  model 

Although  no  actual  software  development  needs  to  be  performed  to  satisfy 
this  aspect  of  a  Class  Bl  TCB,  seme  consideration  needs  to  be  made  for  it 
during  the  design  phase  for  the  system  as  a  whole.  During  the  Design  These 
the  system  developer  needs  to  identify  a  model  of  the  security  policy  that 
can  be  used  to  establish  consistency  between  the  security  policy  and  the 
system  design.  This  consistency  should  be  demonstrated  prior  to  the 
commencement  of  the  coding  phase  so  that  design  modifications  are  eliminated 
in  the  latter  stages  of  the  system  development. 
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3.1.4  Documentation 
(Cl): 

Documentation  is  an  important  part  of  the  software  development  process.  It 
aids  users  who  are  not  familiar  with  the  system  in  learning  hew  to  use  the 
system  correctly.  It  aids  support  programmers  in  testing  the  system  to 
ensure  that  a  modification  has  not  had  a  negative  impact  on  the  system,. 
This  is  especially  important  when  developing  a  TCB,  because  the  security  cl 
the  system  is  of  the  utmost  importaioe.  While  this  is  true,  no  special 
consideration  needs  to  be  given  to  the  development  of  the  documentation  for 
a  TCB.  The  documentation  must  be  developed  to  meet  all  requirements  set 
forth  in  the  TCSEC,  and  must  be  complete  and  up-to-date;  however,  this  is 
not  particular  to  this  development  and  requires  no  further  discussion. 


3. 1.4.1  Security  Features  User’s  Guide 


(Cl): 

o  Single  summary,  chapter,  or  manual  in  user  documentation  shall  describe 
the  protection  mechanisms  provided  by  the  TCB,  guidelines  on  their  use, 
and  hew  they  interact  with  one  another 

3. 1.4.2  Trusted  Facility  Manual. 

(Cl): 

o  Manual  addressed  to  the  ADP  system  administrator  shall  present  cautions 
about  functions  and  privileges  that  should  be  controlled  when  running  a 
secure  facility 


(C2) : 


o  The  procedures  for  examining  and  ite.inraining  the  audit  files,  as  well 
as  the  detailed  audit  record  structure  for  each  type  of  audit  event, 
shall  be  given. 

o  Manual  shall  describe  the  operator  and  administrator  functions  related 
to  security,  to  include  diamine'  the  seam'  /  characteristics  of  a 
user 
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the  protection  features  of  the  system,  hew  they  interact,  hew  to 
securely  generate  a  new  TCB,  and  facility  procedures,  warnings,  and 
privileges  that  need  to  be  controlled  in  order  to  operate  the  facility 
in  a  secure  manner 
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3 . 1 . 4 . 3  Test  Documentation 
(Cl): 

o  System  developer  shall  provide  to  the  evaluators  a  document  that 
describes  the  test  plan,  test  procedures  that  show  hew  the  security 
mechanisms  were  tested,  and  results  of  the  security  mechanisms ' 
functional  testing 

3. 1.4. 4  Design  Documentation 
(Cl): 

o  Documentation  shall  be  available  that  provides  a  description  of  the 
manufacturer's  philosophy  of  protection  and  an  explanation  of  how  this 
philosophy  is  translated  into  the  TCB 

o  If  the  TCB  is  composed  of  distinct  modules,  the  interfaces  between 
these  modules  shall  be  described 

o  An  informal  or  formal  description  of  the  security  policy  model  enforced 
by  the  TCB  shall  be  available  and  an  explanation  provided  to  shew  that 
it  is  sufficient  to  enforce  the  security  policy 
o  Specific  TCB  protection  mechanisms  shall  be  identified  and  an 
explanation  given  to  show  that  they  satisfy  the  model 
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3.2  CLASS  B2:  STRUCTURED  PROTECTION 

"In  class  B2  systems,  the  TCB  is  based  on  a  clearly  defined  and  documented  formal 
security  policy  model  that  requires  the  discretionary  and  mandatory  access 
control  enforcement  found  in  class  B1  systems  be  extended  to  all  subjects  and 
objects  in  the  ADP  system.  In  addition,  covert  channels  are  addressed.  Hie  TCB 
must  be  carefully  structured  into  protection-critical  and  non-protection-critical 
elements.  The  TCB  interface  is  well-defined  and  the  TCB  design  and 
implementation  enable  it  to  be  subjected  to  more  thorough  testing  and  more 
complete  review.  Authentication  mechanisms  are  strengthened,  trusted  facility 
management  is  provided  in  the  form  of  support  for  system  administrator  and 
operator  functions,  and  stringent  configuration  management  controls  are  imposed. 
The  system  is  relatively  resistant  to  penetration." 

3.2.1  Security  Policy 

3. 2. 1.1  Discreticrary  Access  Control 

(Cl) : 

o  TCB  shall  define  and  control  access  between  named  users  and  named 
objects  in  the  ADP  system 

o  Enforcement  mechanism  shall  allow  users  to  specify  and  control  sharing 
of  those  objects  by  named  individuals  or  defined  groups  of  individuals, 
or  both,  and  shall  provide  controls  to  limit  propagation  of  access 
rights. 


(C2) : 

o  Discretionary  access  control  mechanism  shall,  either  by  explicit  user 
action  or  default,  provide  that  objects  are  protected  from  unauthorized 
access 

o  Access  controls  shall  be  capable  of  including  or  excluding  access  to 
the  granularity  of  a  single  user 

o  Access  permission  to  an  object  by  users  not  already  possessing  access 
permission  shall  only  be  assigned  by  authorized  users 

Requirements: 

(Cl): 


Identify  all  types  of  users  for  the  system,  including  individual  users 
and  groups  of  users 

Identify  all  types  of  objects  (e.g.,  files  and  programs)  in  the  system 
Identify  the  level  of  sensitivity  for  the  data  within  the  system 
Describe  all  possible  interactions  between  the  users  and  the  data 
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Identify’  the  enteric  for  determining  the  need  of  a  parti  on  ar  user  tc 
access  a  particular  onect 

(C2) : 

Identify  specific  individuals  to  be  included  in  each  group  of  users 
Design: 

(Cl) : 


Establish  the  method  for  maintaining  the  enforcement  mechanism  (e.g., 
self/group/public  controls,  access  control  lists) 

Establish  the.  method  of  controlling  access  to  objects  within  the  domain 
of  the  TCB 

Establish  the  criteria  for  determining  the  need  of  a  particular  user  to 

access  a  particular  object 

Establish  mechanism  for  identifying  users 

Coding: 

(Cl): 


Use  a  defensive  programming  methodology,  including  hooks  to  aid  testing 
and  maintenance 

Support..; 

(Cl): 


Re-test  system  upon  completion  of  modification 

Ensure  that  enforcement  mechanism  access  control  lists  are  maintained, 
e.g.,  adding  new  users  to  the  access  control  lists  and  removing  users 
from  the  access  control  lists  who  no  longer  require  access  to  the 
system 


3. 2. 1.2  Object  Reuse 
(C2) : 

o  TCB  shall  assure  that  when  a  storage  object  is  initially  assigned, 


-w  a  jcwu 
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storage  objects,  the  object  contains  no  data  for  which  the  subject  is 
not  authorized 
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Requirements: 
(C2) : 


Identify  all  situations  in  which  a  storage  object  is  initially 
assigned,  allocated,  or  reallocated  fran  the  TCB's  pool  of  unused 
storage  objects 

Identify  methods  for  removing  data  fran  objects 


Design: 
(C2) : 


Establish  a  method  for  determining  authorization  of  subject  for  object 
Establish  a  method  for  removing  data  for  which  subject  is  not 
authorized 

3. 2. 1.3  Labels 

o  Sensitivity  labels  associated  with  each  ADP  system  resource  (e.q. , 
subject,  storage  object)  that  is  directly  or  indirpchly  accessible  by 
subjects  external  to  the  TCB  shall  be  maintained  by  the  TCB. 

(Bl): 

o  These  labels  shall  be  used  as  the  basis  for  mandatory  access  control 
decisions. 

o  To  import  non-labeled  data,  the  TCB  shall  request  and  receive  from  an 
authorized  user  the  security  level  of  the  data,  and  all  such  actions 
shall  be  auditable  by  the  TCB 

Requirements: 

(Bl): 


Identify  all  ADP  system  subjects  and  storage  objects  that  are  directly 
or  indirectly  accessible  by  subjects  external  to  the  TCB 
Define  a  policy  for  associating  sensitivity  labels  with  each  ADP  system 
subject  and  storage  object  that  is  directly  or  indirectly  accessible  by 
subjects  external  to  the  TCB.  including  the  import  of  non-labeled  data 
and  the  export  of  labeled  data 
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Design: 

(Bl): 


Establish  a  mechanism  for  implementing  and  managing  the  sensitivity 
labels 

Establish  an  interaction  between  sensitivity  labeling  and  the  audit 
function 

Establish  a  mechanism  for  changing  and  monitoring  the  sensitivity 
designation 


3. 2. 1.3.1  Label  Integrity 
(Bl): 

o  Sensitivity  labels  shall  accurately  reflect  security  levels  of  the 
specific  subjects  or  objects  with  which  they  are  associated 
o  Sensitivity  labels  shall  accurately  reflect  the  internal  labels  and 
shall  be  associated  with  exported  information 

Requirements: 

(Bl) : 


Identify  the  data  required  for  sensitivity  labels  to  accurately  and 
unambiguously  represent  security  levels  of  specific  subjects  or  objects 
with  which  they  are  associated. 

Design: 

(Bl): 


Establish  an  association  between  sensitivity  labels  exported  by  the 
TCB,  with  the  information  being  exported,  such  that  they  accurately  and 
unambiguously  represent  security  levels  of  specific  subjects  or  objects 
with  which  they  are  associated. 


3. 2. 1.3. 2  Exportation  of  labeled  Information 


o  TCB  shall  designate  each  communication  channel  and  I/O  device  as  either 
single-level  or  multilevel;  any  change  in  this  designation  shall  be 
done  manually  and  shall  be  auditable  by  the  TCB 
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TCB  snail  maintain,  anc  re  arie  t.c  audit  any  change  in  one  current 
security  level  associates  with  a  single  communication  cnannel  or  1/C 
device 

o  When  TCB  exports  an  object  to  a  multilevel  I/O  device,  the  sensitivity 
label  associated  with  that  object  shall  also  be  exported  and  shall 
reside  on  the  same  physical  medium  as  the  exported  information  and 
shall  be  in  the  same  form 

o  Export  or  import  protocol  used  on  a  multilevel  communication  channel 
shall  provide  for  the  unambiguous  pairing  between  the  sensitivity 
labels  and  the  associated  information 

o  Single-level  I/O  devices  and  single-level  communication  channels  are 
not  required  to  maintain  the  sensitivity  labels  of  the  information  they 
process;  however,  the  TCB  shall  include  a  mechanism  by  which  the  TCB 
and  an  authorized  user  reliably  communicate  to  designate  the  single 
security  level  of  imported  or  exported  information 
o  ADP  system  administrator  shall  be  able  to  specify  printable  names 
associated  with  exported  sensitivity  labels 
o  TCB  shall  mark  the  beginning  and  end  of  all  human-readable,  paged, 
hardcopy  output  with  human-readable  sensitivity  labels  that  properly 
represent  the  sensitivity  of  the  output 
o  TCB  shall,  by  default,  mark  the  top  and  bottom  of  each  page  of  human- 
readable,  paged,  hardcopy  output  with  human-readable  sensitivity  labels 
that  properly  represent  the  overall  sensitivity  level  of  the  page 
o  TCB  shall,  by  default,  mark  other  forms  of  human-readable  output  with 
human-readable  sensitivity  labels  that  properly  represent  the 
sensitivity  of  the  output 

o  TCB  shall  audit  any  override  of  these  marking  defaults 
Requirements: 

(Bl): 


Identify  the  types  of  communication  channels  and  I/O  devices  to  be  used 
with  the  TCB  and  whether  they  are  single-level  or  multilevel  devices 
Define  the  policy  for  establishing/changing  the  security  designation 
associated  with  these  devices 

Define  the  policy  for  handling  the  preparation  and  handling  of  human- 
readable  output,  including  its  form 

Design: 

(Bl) : 


Establish  the  protocol  for  importing  and  exporting  objects  between  the 
TCB  and  secure  single-level  or  multilevel  devices 

Establish  the  mechanism  for  labeling  and  producing  human-readable 
output 
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3. 2. 1.3. 3  Subject  Sensitivity  labels 

o  TCB  shall  iTOnfidiatelv  notify  a  terminal  user  of  each  change  in  the 
security  level  associated  with  that  user  during  can  interactive  session 
o  A  terminal  user  shall  be  able  to  emery  the  TCB  as  desired  fnr  a  display 
of  the  subject's  complete  sensitivity  label 

Requirements: 

Identify  a  means  far  the  TCB  to  automatically  notify  a  terminal  user  of 
each  change  in  the  security  level  associated  with  a  given  user  during 
an  interactive  session 

Identify  a  means  far  a  tormina!  user  to  query  the  TCB  as  desired  for  a 
disnlav  of  the  subject's  ccpplete  sensitivity  label 

To  properly  determine  the  requirements  for  subject  sensitivity  labels  used 
in  a  Class  B2  TCB,  a  means  must  be  identified  to  convey  information  (about 
the  subject  sensitivity)  between  the  user  and  the  TCB.  Thus,  the  TCB  must 
be  able  to  automatically  notify  a  terminal  user  of  each  change  in  the 
security  level  associated  with  a  given  user  during  an  interactive  session. 
In  addition,  a  terminal  user  must  be  able  to  query  the  TCB  as  desired  for  a 
display  of  the  subject's  complete  sensitivity  label.  This  allows  a  subject 
to  remain  fully  informed  of  the  contents  of  his  sensitivity  label  during  a 
session,  including  the  current  security  level  associated  with  it. 


Design: 

-  Establish  a  mechanism  far  the  TCB  to  ant/Tnatirally  notify  a  terminal 
user  of  each  change  in  the  security  level  associated  with  a  given  user 
during  an  interactive  session 

Establish  a  mechanism  for  a  terminal  user  to  query  the  TCB  as  desired 
for  a  display  of  the  subject's  ccpplete  sensitivity  label 

The  design  of  the  mechanism  that  handles  subject  sensitivity  labels  in  a 
Class  B2  TCB  must  satisfy  the  requirements  stated  above.  Thus  a  mechanism 
must  be  established  for  the  TCB  to  automatically  notify  a  terminal  user  of 
each  change  in  the  security  level  associated  with  a  given  user  during  an 
interactive  session.  In  addition,  a  mechanism  must  be  established  for  a 
terminal  user  to  query  the  TCB,-  as  desired,  for  a  display  of  the  subject's 
complete  sensitivity  label.  These  mechanisms  provide  the  means  of  keeping 
the  terminal  user  informed  of  the  contents  of  his  current  sensitivity  level. 
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3. 2. 1.3. 4  Device  labels 

o  ttr  Rhan  support  the  assignment  <~>f  mini-mm  anri  maxi  mm  security  levels 
to  all  attached  physical  devices 

o  Security  levels  shall  he  used  by  the  TCB  to  enforce  constraints  iupnsfid 
by  the  physical  envircrinents  in  which  the  devices  are  located 

Requirements: 

-  Identify  a  means  for  the  TCB  to  support  the  assignment  of  minimum  and 
maximum  security  levels  to  all  attached  physical  devices 

To  properly  determine  the  requirements  for  device  labels  in  a  Class  B2  TCB, 
a  means  must  be  identified  for  the  TCB  to  support  the  assignment  of  minimum 
and  maximum  security  levels  to  all  attached  physical  devices.  This  promotes 
the  maintenance  of  sufficiently  secure  usage  of  the  physical  devices 
controlled  by  the  TCB. 

Design: 

-  Establish  a  marhanism  far  the  TCB  to  support  the  assiarmerit  of  minimum 
and  jnaxiaym  security  levels  to  all  attached  physical  devices 

The  design  of  the  mechanism  for  handling  device  labels  in  a  Class  B2  TCB 
must  satisfy  the  requirements  stated  above.  To  accomplish  this  a  mechanism 
must  be  established  for  the  TCB  to  support  the  assignment  of  minimum  and 
maximum  security  levels  to  all  attached  physical  devices.  This  must  ensure 
that  the  TCB  controls  its  physical  devices  in  a  secure  manner  such  that  the 
security  levels  used  by  the  TCB  enforce  constraints  imposed  by  the  physical 
environments  in  which  the  devices  are  located. 


3. 2. 1.4  Mandatory  Access  Control 

o  TCB  shall  enforce  a  mandatory  access  control  policy  over  all  resources 
(i.e. ,  subjects,  storage  objects  and  I/O  devices)  that  are  directly  or 
indirectly  accessible  by  subjects  external  to  the  TCB 


(Bl) : 

o  All  subjects  and  storage  objects  shall  be  assigned  sensitivity  labels 
that  are  a  combination  of  hierarchical  classification  levels  and  non- 
hierarchical  categories,  and  the  labels  shall  be  the  basis  of  the 
mandatory  access  control  decisions 
o  TCB  shall  be  able  to  support  two  or  moire  security  levels 
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Requirements: 

(Bl): 


Identify  all  resources  that  are  dirpctly  or  irriiracrtlv  accessible  by 
subjects  external  to  the  TCB 

Describe  the  hierarchical  classification  levels  and  non-hierarchical 
categories  within  the  TCB 

Define  the  mandatory  access  control  policy  based  upon  the 
classification  levels  within  the  TCB 

In  developing  the  requirements  for  the  Mandatory  Access  Control  aspect  of  a 
Class  B2  TCB,  the  control  policy  remains  as  for  a  Class  Bl  TCB;  however,  in 
a  Class  B2  TCB,  the  policy  is  applicable  to  all  resources  that  are  directly 
or  indirectly  accessible  by  subjects  external  to  the  TCB.  As  a  result  of 
this  expansion  of  applicability,  the  developer  must,  during  the  requirements 
phase,  identify  all  those  resources  that  meet  the  criteria.  Once  the 
resources  to  be  controlled  have  been  identified,  the  system  development  will 
progress  as  before  except  that  more  resources  need  to  be  considered. 

Design: 

(Bl): 


Establish  a  mechanism  for  implementing  the  mandatory  access  control 
policy 


3.2.2  Accountability 
3. 2. 2.1  Identification  and  Authentication 
(Cl): 

o  TCB  shall  require  users  to  identify  themselves  to  it  before  beginning 
to  perform  any  other  actions  that  the  TCB  is  expected  to  mediate 
o  TCB  shall  maintain  authentication  data  that  includes  information  for 
verifying  the  identity  of  individual  users  as  well  as  information  for 
determining  the  clearance  and  authorizations  of  individual  users 
o  TCB  shall  use  this  data  to  authenticate  the  user’s  identity  and  to 
determine  the  security  level  and  authorizations  of  subjects  that  may  be 
created  to  act  on  the  behalf  of  the  individual  user 
o  TCB  shall  protect  authentication  data  so  that  it  cannot  be  accessed  by 
any  unauthorized  user 
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(C2) : 


o  TCB  shall  be  able  to  enforce  individual  accountability  by  providing  the 
capability  to  uniquely  identify  each  individual  ADP  system  user 
o  TCB  shall  provide  the  capability  of  associating  Che  individual  identity 
with  all  auditable  actions  taken  by  that  individual 

Requirements: 

(Cl): 


Identify  all  actions  to  be  mediated  by  the  TCB,  including  access  to 
authentication  data 

Define  a  standard  format  for  authentication  data 
Determine  a  method  for  identifying  users 

Design: 

(Cl) : 


Establish  a  mechanism  for  identification  and  authentication  of  users 
Establish  a  mechanism  for  creating  and  maintaining  authentication  data 

(C2) : 

Establish  a  mechanism  for  associating  user  identity  with  user  actions 


3. 2. 2. 1.1  Trusted  Path 

o  TCB  shall  support  a  trusted  ccmgjnicatian  path  between  itself  and  user 
for  initial  login  and  authentication 

o  craramicatian  via  this  path  shall  be  initiated  exclusively  by  a  user 
Requirements: 

-  Identify  a  coomni  cation  path  between  the  user  and  the  TCB  that  can  be 
trusted 

-  Identify  all  operations  required  for  the  TCB  to  support  the  trusted 
rmw  ini  ration  path 

in  identifying  the  requirements  for  the  development  of  a  trusted  path  for  a 
Class  B1  TCB,  a  number  of  preliminary  determinations  need  to  be  made. 
First,  the  system  developer  needs  to  identify  the  particular  trusted  path  tc 
be  used  on  the  system  under  development.  This  is  required  prior  to  the  next 
determination,  the  identification  of  all  support  operations  for  the  trusted 
path,  because  different  paths  will  be  supported  in  different  manners.  For 
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example,  if  the-  trustee  path  identified  was  through  a  terminal  that  was 
enclosed  in  a  vault  with  ar,  around-the-clock  guard,  the  support  function  ma\ 
not  need  to  be  as  security  conscious  as  if  the  trusted  path  was  made  through 
the  use  of  a  terminal  in  the  middle  of  an  unsecured  room.  For  the  terminal 
in  the  middle  of  the  unsecured  room,  seme  type  of  front-end  may  need  to  be 
implemented  to  protect  the  path  from  tampering. 

Design: 

Establish  a  mechamsm  for  supporting  the  trusted  path 
-  Establish  a  mechanism  for  enabling  a  user  to  aoness  the  TCB  through  a 
trusted  cxmounicatiosi  path  which  interfaces  with  the  identification  and 
authentication  function 

Once  the  items  in  the  Requirements  phase  have  been  identified,  mechanisms  to 
meet  the  requirements  need  to  be  designed.  In  particular,  each  support 
operation  will  need  to  be  designed  so  that  it  will  operate  in  a  secure 
manner.  In  addition,  a  mechanism  for  allowing  a  user  to  utilize  the  trusted 
path  to  access  the  TCB  will  need  to  be.  established.  Ihis  mechanism  will 
need  to  interface  with  the  identification  and  authentication  function 
developed  for  this  Class  of  TCB  so  that  user  security  is  guaranteed.  Each 
of  these  mechanisms  will  need  to  be  especially  reliable  so  that  the  security 
of  the  TCB  is  not  compromised. 


3. 2. 2. 2  Audit 


(C2) : 

o  TCB  shall  be  able  to  create,  maintain,  and  protect  from  modification  or 
unauthorized  access  or  destruction  an  audit  trail  of  accesses  to  the 
objects  it  protects 

o  Audit  data  shall  be  protected  by  the  TCB  so  that  read  access  to  it  is 
limited  to  those  who  are  authorized  for  audit  data 

o  TCB  shall  be  able  to  record:  use  of  identification  and  authentication 
mechanisms,  introduction  of  objects  into  a  user's  address  space, 
deletion  of  objects,  actions  taken  by  computer  operators  and  system 
administrators  aixl/or  system  security  officers,  and  other  security 
relevant  events. 

o  TCB  shall  be  able  to  audit  any  override  of  human-readable  output 
markings. 

o  For  each  recorded  event,  the  audit  record  shall  identify:  date  and 
time  of  the  event,  user,  type  of  event,  and  success  or  failure  of  the 
event.  For  identification  ana  authentication  events,  the  audit  record 
shall  include  origin  of  request  (terminal  ID) .  ,,For  events  that 
introduce  an  object  into  a  riser's  address  space  and  for  object  deletion 
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events,  the  audit  record  shall  include  the  name  of  the  object  and  the 
object's  security  leve. . 

o  ADP  system  adnvinistrator  shall  be  able  to  selectively  audit  the  actions 
of  any  one  or  more  users  based  on  individual  identity  and/or  object 
security  level . 

o  TCB  ^iall  be  able  to  audit  the  identified  events  that  may  be  used  in 
the  exploitation  of  covert  storage  channels 


Requirements: 


(C2) : 


Identify  all  objects  to  be  protected  by  the  TCB 
Establish  complete  requirements  for  Audit  Function 


Design: 
(C2) : 


Establish  a  mechanism  for  operation  of  the  Audit  Function 


3.2.3  Assurance 

3. 2. 3.1  Operational  Assurance 
3. 2. 3. 1.1  System  Architecture 


(Cl): 

o  TCB  shall  maintain  a  domain  for  its  own  execution  that  protects  it  from 
e>rtemal  interference  or  tampering 


(Bl): 

o  TCB  shall  maintain  process  isolation  through  the  provision  of  distinct 
address  spaces  its  control 

°  TCB  shall  be  internally  structured  into  wall-defined  largely 
independent  modules 

o  TCB  shall  make  effective  use  of  available  hartfoarr  to  separate  those 
elements  that  are  protection-critical  free:  those  thac  are  not 

o  TCB  modules  shall  be  designed  such  that  the  principle  of  least 
privilege  is  enforced 

o  Features  in  hardware,  such  as  segmentation,  shall  be  used  to  support 
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ingiraiiy  d-i<3f  inot-  storage  objects  with  separate  attributes  (nameiv: 
readable .  writable) 

o  ICE  user-interface  stel  1  be  cccpletelv  defined  and  all  elements  of  the 
TCB  identified 

Requirements: 

(Bl): 


Identify  all  resources  and  disc met  address  spaces  to  be  protected  by 
the  TCB,  including  the  TCB  code  and  data  structures 
-  Identify  ail  wavs  in  which  a  user  can  interface  with  the  TCB  by 
identifying  all  elements  of  the  TCB  and  identifying  the  user  interface 
to  each  element 

To  satisfy  the  criteria  for  the  System  Architecture  of  a  Class  B2  TCB,  one 
additional  requirement  needs  to  be  satisfied.  To  satisfy  the  requirement, 
the  user  interface  to  the  TCB  needs  to  be  completely  defined.  First,  all 
elements  of  the  TCB  need  to  be  identified.  Second,  the  user  interface  to 
each  element  needs  to  be  identified.  The  complete  definition  of  the  user 
interface  of  the  TCB  will  then  be  defined  as  the  sum  of  all  of  these 
individual  interactions.  As  an  example,  one  of  the  elements  of  the  TCB 
could  be  a  file  of  data.  The  user  interface  to  that  file  could  only  be 
accomplished  through  use  of  a  program.  Therefore  one  of  the  aspects  of  the 
user  interface  for  the  TCB  would  be  the  module  in  the  program  that  enables 
the  user  access  to  that  file. 

In  addition,  requirements  as  to  how  the  TCB  is  to  be  developed  are  made  in 
the  System  Architecture  requirements  for  a  Class  B2  TCB.  Although  these 
requirements  add  great  detail  to  the  System  Architecture,  they  are  simply 
statements  of  good  Software  Engineering  practices  which  should  be  used  in 
all  systems  development .  As  such,  no  additional  items  need  to  be 
identified. 

Design: 

(C2) : 


Establish  a  method  of  isolating  resources  to  be  protected  by  the  TCB 


(Bl): 


Establish  a  mode  for  protecting  each  resource  and  distinct  address 
space  within  the  TCB 

Establish  the  user  interface  for  the  TCB 
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Onoe  the  requirements  for  the  Syster  Architecture  aspect  of  a  Class  B2  TCP 
nave  been  identified,  the  design  prase  can  commence.  During  the  aesigi 
phase,  as  discussed  in  Class  Bl,  the  system  developer  needs  to  establish  a 
mode  for  protecting  each  resource  and  distinct  address  space  within  the  TCB. 
In  addition,  the  developer  needs  to  design  the  user  interface  in  accordance 
with  the  requirements  set  forth  for  the  System  Architecture.  This  design 
mist  not  only  facilitate  those  operations  that  should  be  allowed,  but  it 
must  also  prohibit  those  operations  that  should  be  disallowed. 


3. 2. 3. 1.2  System  Integrity 
(Cl): 

o  Hardware  and/or  software  features  shall  be  provided  that  can  be  used  to 
periodically  validate  the  correct  operation  of  the  on-site  hardware  and 
firmware  elements  of  the  TCB 

Requirements: 

(Cl): 


Identify  hardware  and  firmware  elements  of  the  TCB  to  be  validated 
Determine  validation  criteria  for  testing  each  element  of  the  TCB 
Determine  the  appropriate  interval  at  which  validation  of  the 
hardware/ f irmware  should  take  place 

Design: 

(Cl): 


Establish  a  method  for  testing  each  criterion  for  each  element  of  the 
TCB 


3. 2. 3. 1.3  Covert  Channel  Analysis 

o  System  developer  shall  conduct  a  thorough  search  for  covert  storage 
channels  and  make  a  determi  nation  of  the  maximum  bandwidth  of  each 
■identified  channel 

The  Covert  Channel  Analysis  for  a  Class  B2  TCB  involves  a  thorough  search, 
by  the  system  developer,  tor  covert  storage  channels.  Inis  search  is  a 
purely  manual  process,  although  the  results  from  the  search  and  actions 
taken  in  response  to  the  search  need  to  be  detailed  in  the  system 
documentation,  no  software  development  needs  to  take  place.  As  such,  a 
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discussion  of  the  Requirements ,  Dasiar.,  Coding,  Testing,  or  Support  phase  ie 
not  necessary. 

3. 2. 3. 1.4  Trusted  Facility  Management 

o  TCB  shall  support  separate  operator  and  administrator  functions 
Requirements: 

Identify  all  functions  to  be  perfrvrmpri  by  the  operator  and 

rwdmi  rh  gtratnr 

The  Trusted  Facility  Management  of  a  Class  B2  TCB  provides  the  system  with 
requirements  for  separate  operator  and  administrator  functions.  In  order  to 
properly  develop  requirements  for  this,  the  system  developer  needs  to 
completely  define  the  roles  of  operator  and  administrator.  Because  these 
roles  are  to  be  maintained  as  separate  functions,  they  must  be  considered 
separately,  and  the  actions  to  be  performed  by  each  must  be  identified.  In 
addition,  any  interaction  between  the  two  functions  needs  to  be  described  in 
detail. 

Design: 

Establish  a  mechanism  for  the  proper  operation  of  each  of  the  functions 
for  the  operator  ana  each  of  the  functions  for  the  administrrator 

Daring  the  design  phase  of  the  development  of  the  operator  and  the 
administrator  functions,  each  of  the  actions  to  be  performed  by  each  of  the 
roles  needs  to  be  considered  as  an  individual  entity.  In  this  phase,  the 
determination  of  hew  each  of  the  actions  will  be  performed  will  be  made. 
Daring  this  phase,  it  is  particularly  important  to  ensure  that  the  actioris 
performed  by  the  operator  and  administrator  oversee  the  actions  of  all  oLner 
users  and  can  contribute  to  the  maintenance  of  the  trust  and  security  of  the 
system  as  a  whole. 


3. 2. 3. 2  Life-Cycle  Assurance 
3. 2. 3. 2.1  Security  Testing 


(Cl): 

o  Security  mechanisms  of  the  ADP  system  shall  be  tested  and  found  to  work 
as  claimed  in  the  system  documentation 
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o  Team  of  individuals  who  thoroughly  understand  tne  specific 

implementation  of  the  TCB  shall  subject  its  design  documentation, 

source  code,  and  object  code  to  thorough  analysis  and  testing.  The 
team's  objectives  will  be  to  uncover  all  design  and  implementation 
flaws  that  would  permit  a  subject  external  to  the  TCB  to  read,  change, 
or  delete  data  normally  denied  under  the  mandatory  or  discretionary 
security  policy,  and  to  ensure  that  no  subject  is  able  to  cause  the  TCB 
to  enter  a  state  such  that  it  is  unable  to  respond  to  communications 
initiated  by  other  users 

o  TCB  shcill  be  found  relatively  resistant  to  penetration. 

o  All  discovered  flaws  shall  be  corrected  and  the  TCB  retested  to 

demonstrate  that  they  have  been  eliminated  and  that  new  flaws  have  not 
been  introduced 

o  Testing  shall  dpnmstrate  that  the  TCB  implementation  is  consistent 
with  the  descriptive  top-level  specification 

Requirements: 

(Cl): 


Identify  security  protection  mechanisms  of  the  TCB  to  be  tested 
Design: 

(Bl): 


Establish  means  of  testing  each  security  protection  mechanism  in  a 
manner  consistent  with  the  stringent  requirements  derailed  ir.  the  TCSEC 

Coding: 

(Cl): 


Use  prudently  placed  debug  statements  to  allow  the  tester  to  monitor 
operation  of  the  security  mechanisms 


3. 2. 3. 2. 2  Design  Specification  and  Verification 

o  Formal  model  of  the  security  policy  supported  by  the  TCB  shall  be 
maintained  that  is  proven  to  be  consistent  with  its  axioms 
o  A  descxiptive  top-level  specification  (DTPS}  of  the  TCB  shall  be 
mainta~ir>Pd  that  ociroletelv  and  accurately  describes  the  TCB  in  terms  of 
exceptions,  error  messages,  and  effects.  It  shall  be  shown  to  be  an 
accurate  description  of  the  TCB  interface. 
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Design: 

(Bl): 


Identify  the  model  to  be  utilized 

Prove  consistency  between  design  and  the  model 

As  discussed  previously  in  Class  Bl,  the  Design  Specification  and 
verification  of  a  TCB  does  not  require  any  software  development;  however,  it 
does  need  to  be  considered  during  the  design  phase  of  the  software 
development  for  the  TCB  as  a  whole.  During  the  design  phase,  the  model  to 
be  used  must  be  chosen.  In  a  Class  B2  TCB,  this  is  required  to  be  a  formal 
model.  The  consistency  between  the  design  and  the  chosen  model  needs  to  be 
formally  proven.  This  formal  proof  entails  the  development  of  "a  complete 
and  convincing  mathematical  argument  to  present  full  logical  justification 
for  each  proof  step,  for  the  truth  of  a  theorem,  or  set  of  theorems."  To 
satisfy  this  aspect  of  the  development  of  a  Class  B2  TCB,  this  proof  will 
need  to  be  formalized  during  the  design  phase  of  the  system  development. 


3. 2. 3. 2. 3  configuration  Management 

o  A  configuration  management  system  shall  be  in  place  that  maintains 
control  of  changes  to  the  descriptive  top-level  specification  (PTES) , 
other  design  data,  implementation  documentation,  source  code,  the 
running  version  of  the  object  code,  and  test  fixtures  and  documentation 
o  The  oonfiquration  management  system  shall  assure  a  consistent  mapping 
among  all  documentation  and  code  associated  with  the  current  version  of 
the  TCB 

o  Idols  shall  be  provided  for  generating  a  new  version  of  the  TCB  from 
source  code  and  far  cccoparing  a  newly  generated  version  with  the 
previous  TCB  version  in  order  to  ascertain  that  only  the  intended 
changes  have  been  made  in  the  code  that  will  actually  be  used  as  the 
new  version  of  the  TCB 


The  development  of  any  large  system  requires  the  introduction  and  proper  lose 
of  seme  type  of  Configuration  Management  System.  The  development  of  a  TCB 
is  no  exception  to  this  rule;  however,  as  it  pertains  to  our  discussion, 
Configuration  Management  does  not  require  any  special  considerations.  A 
Configuration  Management  System,  which  will  guarantee  that  the  requirements 
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3.2.4  Documentation 
(Cl): 

Documentation  is  an  important  part  of  the  software  development  process.  It 
aids  users  who  are  not  familiar  with  the  system  in  learning  how  to  use  the 
system  correctly.  It  aids  support  programmers  in  testing  the  system  to 
ensure  that  a  modification  has  not  had  a  negative  impact  on  the  system. 
This  is  especially  important  when  developing  a  TCB,  because  the  security  of 
the  system  is  or  the  utmost  importance.  While  this  is  true,  no  special 
consideration  needs  to  be  given  to  the  development  of  the  documentation  for 
a  TCB.  The  documentation  must  be  developed  to  meet  all  requirements  set 
forth  in  the  TCSEC,  arri  must  be  complete  and  up-to-date;  however,  this  is 
not  particular  to  this  development  and  requires  no  further  discussion. 

3.2.4. 1  Security  Features  User's  Guide 


(Cl): 

o  Single  summary,  chapter,  or  manual  in  user  documentation  shall  describe 
the  protection  mechanisms  provided  by  the  TCB,  guidelines  on  their  use, 
and  how  they  interact  with  one  another 


3. 2. 4. 2  Trusted  Facility  Manual 


(Cl): 

o  Manual  addressed  to  the  ADP  system  administrator  shall  present  cautions 
about  functions  and  privileges  that  should  be  controlled  when  running  a 
secure  facility 


(C2) : 

o  The  procedures  for  examining  and  maintaining  the  audit  files,  as  well 
as  the  detailed  audit  record  structure  for  each  type  of  audit  event, 
shall  be  given. 


(Bl): 

o  Manual  shall  describe  the  operator  and  administrator  functions  related 
to  security,  to  include  changing  the  security  characteristics  of  a  user 
c  Manual  shall  provide  guidelines  on  the  consistent  and  effective  use  of 
the  protection  features  of  the  system,  how  they  interact,  how  to 
securely  generate  a  new  TCB,  and  facility  procedures,  warnings,  and 
privileges  that  need  to  be  controlled  in  order  to  operate  the  facility 
in  a  secure  manner 
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o  TCB  modules  that  contain  the  reference  validation  mechanism  shall  )y 
identified 

o  Procedures  for  secure  generation  of  a  new  TCB  firm  source  after 
modification  of  any  modules  in  the  TCB  shall  be  described 


3. 2. 4. 3  Test  Documentation 

(Cl): 

o  System  developer  shall  provide  to  the  evaluators  a  document  that 
describes  the  test  plan,  test  procedures  that  show  how  the  security 
mechanisms  were  tested,  and  results  of  the  security  mechanisms' 
functioned  testing 

o  Documentation  shall  include  results  of  testing  the  effectiveness  of  the 
mettads  used  to  reduce  covert  channel  bandwidths 

3. 2. 4. 4  Design  Documentation 
(Cl): 

o  Documentation  shall  be  available  that  provides  a  description  of  the 
manufacturer's  philosophy  of  protection  and  an  explanation  of  how  this 
philosophy  is  translated  into  the  TCB 
o  The  interfaces  between  the  TCB  modules  shall  be  described 
o  A  formal  description  of  the  security  policy  model  enforced  by  the  TCB 
shall  be  available  and  proven  that  is  sufficient  to  enforce  the 
security  policy 

o  Specific  TCB  protection  mechanisms  shall  be  identified  and  an 
explanation  given  to  show  that  they  satisfy  the  model 
o  The  DUS  shall  be  shown  to  be  an  accurate  description  of  the  TCB 
interface 

o  Documentation  shall  describe  how  the  TCB  implements  the  reference 
monitor  concept  and  give  an  explanation  why  it  is  tamper  resistant, 
cannot  be  bypassed,  and  is  correctly  inulemented. 
o  Documentation  shall  describe  how  the  TCB  is  structured  to  facilitate 
testing  and  to  enforce  least  privilege 
o  Documentation  shall  also  present  the  results  of  covert  channel  analysis 
and  the  tradeoffs  involved  in  restricting  the  channels 
o  All  auditable  events  that  may  be  used  in  the  exploitation  of  known 
covert  storage  channels  shall  be  identified 
o  The  bandwidths  of  known  covert  storage  charnels,  the  use  of  which  is 
not  detectable  by  the  auditing  mechanism?;-  shall  be  provided 
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3.3  CLASS  B3:  SECURITY  DCMAINS 

"Hie  class  B3  TCB  must  satisfy  the  reference  monitor  requirements  that  it  mediate 
all  accesses  of  subjects  to  objects,  be  tamperproof,  and  be  small  enough  to  be 
subjected  to  analysis  and  tests.  To  this  end,  the  TCB  is  structured  to  exclude 
code  not  essential  to  security  policy  enforcement,  with  significant  system 
engineering  during  TCB  design  and  implementation  directed  toward  minimizing  its 
complexity.  A  security  administrator  is  supported,  audit  mechanisms  are  expanded 
to  signal  security-relevant  events,  and  system  recovery  procedures  are  required. 
The  system  is  highly  resistant  to  penetration." 

3.3.1  Security  Policy 

3. 3. 1.1  Discretionary  Access  Control 

(Cl): 

o  TCB  shall  define  and  control  access  between  named  users  and  named 

objects  in  the  ADP  system 

o  Enforcement  mechanism  (e.q. ,  access  control  lists)  shall  allow  users  to 

specify  and  control  sharing  of  those  objects,  and  shall  provide 

controls  to  limit  propagation  of  access  rights 

(C2): 

o  Discretionary  access  control  mechanism  shall,  either  by  explicit  user 
action  or  default,  provide  that  objects  are  protected  from  unauthorized 
access 

o  Access  controls  shall  be  capable  of  specifying,  far  each  named  object. 

a  list  of  named  individuals  and  a  list  of  groups  of  named  individuals 
with  their  respective  modes  of  access  to  that  object:  furthermore,  for 
each  such  named  object,  it  shall  be  possible  to  specify  a  list  of  named 
individuals  and  a  list  of  groups  of  named  individuals  for  which  no 


access  to  the  object  is  to  be  given 

o  Access  permission  tc  an  object  by  users  not  already  possessing  access 
permission  shall  only  be  assigned  by  authorized  users 

Requirements: 

(Cl): 

Identify  all  types  of  users  for  the  system,  including  individual  users 
and.  groups  of  users 

Identify  all  types  of  objects  (e.g. ,  files  and  programs)  in  the  system 
Identify  the  level  of  sensitivity  for  the  data  within  the  system 
Describe  all  possible  interactions  between  the  users  and  the  data 
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Identify-  the  criteria  for  determining  the  need  of  a  parti  era]  ar  user  tc 
access  a  partiCLuar  oriect 

(C2) : 

Identify  specific  individuals  to  be  included  in  each  group  of  users 
Design: 

(Cl): 


Establish  a  method  for  maintaining  the  enforcement  mechanism  (e.g. , 
self/group/public  controls,  access  control  lists) 

Establish  a  method  of  controlling  access  to  objects  within  the  domain 
of  the  TCB 

Establish  criteria  for  determining  the  need  of  a  particular  user  to 

access  a  particular  object 

Establish  a  mechanism  for  identifying  users 

Coding: 

(Cl): 


Use  a  defensive  programming  methodology,  including  hooks,  to  aid 
testing  and  maintenance 

Support: 

(Cl): 


Re-test  system  upon  completion  of  modification 

Ensure  that  enforcement  mechanism  access  control  lists  are  maintained, 
e.g. ,  adding  new  users  to  the  access  control  lists  and  removing  users 
from  the  access  control  lists  who  no  longer  require  access  to  the 
system! 


3. 3. 1.2  Object  Reuse 
(C2) : 

o  TCB  shall  assure  that  when  a  storage  object  is  initially  assigned, 
allocated,  or  reallocated  to  a  subject  from  the  TCB’s  pool  of  unused 
storage  objects,  the  abject  contains  no  data  for  which  the  subject  is 
not  authorized 
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Requirements: 

(C2) : 

Identic  all  situations  in  which  a  storage  object  is  initially 
assigned,  allocated,  or  reallocated  from  the  TCB's  pool  of  unused 
storage  objects 

Identify  methods  for  removing  data  from  objects 
Design: 

(C2): 

Establish  a  method  for  determining  authorization  of  subject  for  object 
Establish  a  method  for  removing  data  for  which  subject  is  not 
authorized 

3. 3. 1.3  labels 

(B2) : 

o  Sensitivity  labels  associated  with  each  ADP  system  resource  (e.g., 
subject,  storage  object)  that  is  directly  or  indirectly  accessible  by 
subjects  external  to  the  TCB  shall  be  maintained  by  the  TCB 

(Bl): 

o  Ihese  labels  shall  be  used  as  the  basis  for  mandatory  access  control 
decisions. 

o  To  import  non-labeled  data,  the  TCB  shall  request  and  receive  from  an 
authorized  user  the  security  level  of  the  data,  and  all  such  actions 
shall  be  auditable  by  the  TCB 

Requirements: 

(B2) : 

Identify  all  ADP  system  subjects  and  storage  objects  that  are  directly 
or  indirectly  accessible  by  subjects  external  to  the  TCB 
Define  a  policy  for  associating  sensitivity  labels  with  each  ADP  system 
subject  and  storage  object  that  is  directly  or  indirectly  accessible  by 
subjects  external  to  the  TCB,  including  the  inport  of  non-labeled  data 
and  the  export  of  labeled  data 
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Design: 

(Bl): 

Establish  a  mechanism  for  implementing  and  managing  the  sensitivity 
labels 

Establish  an  interaction  between  sensitivity  labeling  and  the  audit 
function 

Establish  a  mechanism  for  changing  and  monitoring  the  sensitivity 
designation 


3. 3. 1.3.1  Label  Integrity 


(Bl): 

o  Sensitivity  labels  shall  accurately  reflect  security  levels  of  the 
specific  subjects  or  objects  with  which  they  are  associated 
o  Sensitivity  labels  shall  accurately  reflect  the  internal  labels  and 
shall  be  associated  with  exported  information 

Requirements: 

(Bl): 


Identify  the  data  required  for  sensitivity  labels  to  accurately  and 
unambiguously  represent  security  levels  of  specific  subjects  or  objects 
with  which  they  are  associated 

Design: 

(Bl): 


Establish  an  association  between  sensitivity  labels  exported  by  the 
TCB,  with  the  information  being  exported,  such  that  they  accurately  and 
unambiguously  represent  security  levels  of  specific  subjects  or  objects 
with  which  they  are  associated 


3.3. 1.3.2  Exportation  of  labeled  Information 


o  TCB  shall  designate  each  communication  channel  and  I/O  device  as  either 
single-level  or  multilevel;  any  change  in  this  designation  shall  be 
done  manually  and  shall  be  auditable  by  the  TCB 
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c  'PCB  shall  maintain  and  be  ar>3e  to-  audit  any  change  ir  the  current 
security  level  associatec  with;  a  single  ccnununication  cnanne-  or  I/C 
device 

o  When  TCB  exports  an  object  to  a  multilevel  I/O  device,  the  sensitivity 
label  associated  with  that  object  shall  also  be  exported  and  shall 
reside  on  the  same  physical  medium  as  the  exported  information  and 
shall  be  in  the  same  form 

o  Expert  or  import  protocol  used  on  a  multilevel  communication  channel 
shall  provide  for  the  unambiguous  pairing  between  the  sensitivity 
labels  and  the  associated  information 

o  Single-level  I/O  devices  and  single-level  cxrmunication  channels  are 
not  required  to  maintain  the  sensitivity  labels  of  the  information  they 
process;  however,  the  TCB  shall  include  a  mechanism  by  which  the  TCB 
and  an  authorized  user  reliably  communicate  to  designate  the  single 
security  level  of  imported  or  exported  information 
o  ADP  system  administrator  shall  be  able  to  specify  printable  names 
associated  with  exported  sensitivity  labels 
o  TCB  shall  mark  the  beginning  and  end  of  all  human-readable,  paged, 
hardcopy  output  with  human-readable  sensitivity  labels  that  properly 
represent  the  sensitivity  of  the  output 
o  TCB  shall,  by  default,  mark  the  top  and  bottom  of  each  page  of  human- 
readable,  paged,  hardcopy  output  with  human-readable  sensitivity  labels 
that  properly  represent  the  overall  sensitivity  level  of  the  page 
o  TCB  shall,  by  default,  mark  other  forms  of  human-readable  output  with 
human-readable  sensitivity  labels  that  properly  represent  the 
sensitivity  of  the  output 

o  TCB  shall  audit  any  override  of  these  marking  defaults 
Requirements: 

(Bl): 


Identify  the  types  of  communication  channels  and  I/O  devices  to  be  used 
with  the  TCB  and  whether  they  are  single-level  or  multilevel  devices 
Define  the  policy'  for  establishing/changing  the  security  designation 
associated  with  these  devices 

Define  the  policy  for  preparing  and  handling  human-readable  output, 
including  its  form 

Design: 

(Bl): 


Establish  the  protocol  for  Importing  and  exporting  objects  between  the 
TCB  and  secure  single-level  or  multilevel  devices 

Establish  the  mechanism  for  labeling  and  producing  human-readable 
output 
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3. 3. 1.2. 3  Subject  Sensitivity  Labels 


(B2) : 

o  TCB  shall  immediately  notify  a  terminal  user  of  each  change  in  the 
security  level  associated  with  that  user  during  an  interactive  session 
o  A  terminal  user  shall  be  able  to  query  the  TCB  as  desired  for  a  display 
of  the  subject's  complete  sensitivity  label 

Requirements: 

(B2) : 


Identify  a  means  for  the  TCB  to  automatically  notify  a  terminal  user  of 
each  change  in  the  security  level  associated  with  a  given  user  during 
an  interactive  session 

Identify  a  means  for  a  terminal  user  to  query  the  TCB  as  desired  for  a 
display  of  the  subject's  complete  sensitivity  label 

Design: 

(B2) : 


Establish  a  mechanism  for  the  TCB  to  automatically  notify  a  terminal 
user  of  each  change  in  the  security  level  associated  with  a  given  user 
during  an  interactive  session 

Establish  a  mechanism  for  a  terminal  user  to  query  the  TCB  as  desired 
for  a  display  of  the  subject's  complete  sensitivity  label 


3. 3. 1.3. 4  Device  labels 


(B2: : 

o  TCB  shall  support  the  assignment  of  minimum  and  maximum  security  levels 
to  all  attached  physical  devices 

o  Security  levels  shall  be  used  by  the  TCB  to  enforce  constraints  imposed 
by  the  physical  environments  in  which  the  devices  are  located 

Requirements: 

(B2) : 


Identify  a  means  for  the  TCB  to  support  the  assignment  of  minimum  and 
maximum  security  levels  to  all  attached  physical  devices 
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Design: 
(B2) : 


Establish  a  mechanism  for  the  TCB  to  support  the  assignment  of  minimum 
and  maximum  security  levels  to  all  attached  physical  devices 


3. 3. 1.4  Mandatory  Access  Control 


(B2) : 

o  TCB  shall  enforce  a  mandatory  access  control  policy  over  all  resources 
(i.e. ,  subjects,  storage  objects,  and  I/O  devices)  that  are  directly  or 
indirectly  accessible  by  subjects  external  to  the  TCB 


(Bl): 

o  All  subjects  and  storage  objects  shall  be  assigned  sensitivity  labels 
that  are  a  combination  of  hierarchical  classification  levels  and  non- 
hierarchical  categories,  and  the  labels  shall  be  the  basis  of  the 
mandatory  access  control  decisions 
o  TCB  shall  be  able  to  support  two  or  more  security  levels 


Requirements: 

(Bl): 


Describe  the  hierarchical  and  non-hierarchical  classification  levels 
within  the  TCB 

Define  the  mandatory  access  control  policy  based  upon  the 
classification  levels  within  the  TCB 


(B2) : 


Identify  all  resources  that  are  directly  or  indirectly  accessible  by 
subjects  external  to  the  TCB 

Design: 

(Bl) : 


Establish  a  mechanism  for  implementing  the  mandatory  access  control 
policy 
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3.3.?  Accountability 

3. 3. 2.1  Identification  and  Aiitheirticatian 


(Cl): 

o  TCB  shall  require  users  to  identify  themselves  to  it  before  beginning 
to  perform  any  other  actions  that  the  TCB  is  expected  to  mediate 
o  TCB  shall  maintain  authentication  data  that  includes  information  for 
verifying  the  identity  of  individual  users  as  well  as  information  for 
determining  the  clearance  and  authorizations  of  individual  users 
o  TCB  shall  use  this  data  to  authenticate  the  user's  identity  and  to 
determine  the  security  level  and  authorizations  of  subjects  that  may  be 
created  to  act  on  the  behalf  of  the  individual  user 
o  TCB  shall  protect  authentication  data  so  than  it  cannot  be  accessed  by 
any  unauthorized  user 


(C2) : 

o  TCB  shall  be  able  to  enforce  individual  accountability  by  providing  the 
capability  to  uniquely  identify  each  individual  ADP  system  user 
o  TCB  shall  provide  the  capability  of  associating  the  individual  identity 
with  all  auditable  actions  taken  by  tliat  individual 

Requirements: 

(Cl): 


Identify  all  actions  to  be  mediated  by  the  TCB,  including  access  to 
authentication  data 

Define  a  standard  format  for  authentication  data 
Determine  a  method  for  identifying  users 

Design: 

(Cl) : 


Establish  a  mechanism  for  identifying  and  authenticating  users 
Establish  a  mechanism  for  creating  and  maintaining  authentication  data 

(C2) : 

Establish  a  mechanism  for  associating  user  identity  with  user  actions 
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3. 3. 2. 1.1  Trusted  Path 

o  TCB  shall  support  a  trusted  cosnmunication  path  between  itself  and  users 
for  use  what  a  positive  TCB-to-user  connection  .is  required  (e.g.  f 
login,  change  subject  security  level) 

o  crrmunication  via  this  trusted  path  shall  be  activated  exclusively  by  a 
user  or  the  TCB  and  shall  be  logically  isolated  and  unmistakably 
dighinonishable  free  other  paths 

Requirements: 

(B2) : 


Identify  a  trusted  communication  path  between  the  user  and  the  TCB 
Identify  all  operations  required  for  the  TCB  to  support  the  trusted 
communication  path 

Design: 

(B2) : 


-  Establish  a  mechanism  for  supporting  the  trusted  path 

Establish  a  mechanism  for  enabling  user-to-TCB  and  TCB-to-user  access 
via  the  trusted  communication  path  which  interfaces  with  the 
identification  and  authentication  function 

The  Trusted  Path  for  a  Class  B3  TCB  needs  to  allow  bi-directional  access, 
from  user  to  TCB  and  from  TCB  to  user.  This  consideration  must  Tme  into 
play  when  developing  the  design  for  the  mechanism  that  will  enable  this 
access.  All  other  items  from  the  Class  B2  TCB  also  apply  here. 


E.3.2.2  Audit 
(C2): 

o  TCB  shall  be  able  to  create,  maintain,  and  protect  from  modification  or 
unauthorized  access  or  destruction  an  audit  trail  of  accesses  to  the 
objects  it  protects 

o  Audit  data  shall  be  protected  by  the  TCB  so  that  read  access  to  it  is 
limited  to  those  who  are  authorized  for  audit  data 
o  TCB  shall  be  able  to  record:  use  of  identification  and  authentication 
mechanisms,  introduction  of  objects  into  a  user's  address  space, 
deletion  of  objects,  actions  taken  by  computer  operators  and  system 
administrators  arri/c.;:  system,  security  officers,  and  other  security 
relevant  events. 
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'  TCB  shall  be  able  be  audit  any  override  of  human-readable  output 
markings . 

o  For  each  recorded  event,  the  audit  record  shall  identify:  date  and  time 
of  event,  user,  type  of  event,  and  success  or  failure  of  the  event. 
For  identification  and  authentication  events,  the  audit  record  shall 
include  origin  of  request  (terminal  IB) .  For  events  that  introduce  an 
abject  into  a  user's  address  space  and  for  object  deletion  events,  the 
audit  record  shall  include  the  name  of  the  object  and  the  object's 
security  level. 

o  ADP  system  administrator  shall  be  able  to  selectively  audit  the  actions 
of  any  one  or  more  users  based  on  individual  identity  and/or  object 
security  level. 


(B2) : 

o  TCB  shall  be  able  to  audit  the  identified  events  that  may  be  used  in 
the  exploitation  of  covert  storage  channels 

o  TCB  shall  contain  a  mechanism  that  is  able  to  monitor  the  occurrence  or 
accumulation  of  security  auditable  events  that  may  indicate  an  inminent 
violation  of  security  policy;  this  mechanism  shall  be  able  to 
i  wired  lately  notify  the  security  administrator  when  thresholds  are 
exceeded  and,  if  the  occurrence  or  accumulation  of  the***  security 
relevant  events  oontmies.  the  system  shall  take  the  least  disruptive 
action  to  terminate  the  event 

Requirements: 

(C2) : 


Identify  all  objects  to  be  protected  by  the  TCB 
Establish  complete  requirements  for  Audit  Function 
-  Define  criteria  for  indication  of  an  imminent  violation  of  security 
policy 

The  requirements  for  the  auditing  functions  in  a  Class  B3  TCB  must  include 
those  of  Classes  C2,  Bl,  and  B 2.  In  addition,  a  criteria  must  be  defined 
for  the  indication  of  an  imminent  violation  of  the  security  policy.  This 
criteria  requires  that  these  additional  auditing  functions  must  be  able  to 
monitor  the  occurrence  or  accumulation  of  security  auditable  events  that  may 
indicate  such  violations.  Thus,  these  additional  events  must  be  accounted 
for  in  the  audit  trail. 

resign: 

(C2) : 


Establish  a  mechanism  for  operation  of  * .  2  Audit  Function 
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Etesictn  3  meciianisn-  t~  monitor  security  auditable  events  arri  to  noti*- 
security  actomistrator 

The  design  of  the  auditing  functions  in  a  Class  B3  TCB  must  satisfy  the 
requirements  stated  above.  Thus,  its  design  should  incorporate  that  of 
Classes  C2,  Bl,  and  B2.  In  addition,  it  must  include  the  design  of  a 
mechanism  to  monitor  security  auditable  events  and  to  notify  the  security 
administrator  accordingly.  This  is  to  ensure  that  the  security 
administrator  is  kept  well  informed  of  such  events  so  that  he  can  take 
appropriate  and  prcrnpt  action  in  response  to  their  occurrence. 


3.3.3  Assurance 

3. 3. 3.1  Operational  Assurance 
3. 3. 3. 1.1  System  Architecture 


(Cl): 

o  TCB  shall  maintain  a  domain  for  its  own  execution  that  protects  it  from 
external  interference  or  tampering 


(Bl): 

o  TCB  shall  maintain  process  isolation  through  the  provision  of  distinct 
address  spaces  under  its  control 


(B2) : 

o  TCB  shall  be  internally  structured  into  well-defined  largely 
independent  modules 

o  TCB  shall  make  effective  use  of  available  hardware  to  separate  those 
elements  that  are  protection-critical  from  those  that  are  not 

o  TCB  modules  shall  be  designed  such  that  the  principle  of  least 
privilege  is  enforced 

o  Features  in  hardware,  such  as  segmentation,  shall  be  used  to  support 
logically  distinct  storage  objects  with  separate  attributes  (namely: 
readable,  writable) 

o  TCB  user  interface  shall  be  completely  defined  and  all  elements  of  the 
TCB  identified 

o  TCB  shaJI  he  designed  and  structured  to  use  a  complete,  cxynoeptuallv 
sinple  protection  mechanism  with  precisely  defined  semantics;  this 
Tnprhanism  shall  play  a  central  role  in  enforcing  the  internal 
structuring  of  the  TCB  aid  the  system 

o  TCP,  efran  incorporate  significant  use  of  layering,  abstraction,  and 
data  hiding.  Significant  system  engineering  shall  be  directed  toward 
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TniniTri.rirp  the  ccoc)3e>:ity  of  the  TCP  and  cxcludirr;  tree  the  'JC1  mcriulre-- 
that.  are  net  protect!  orr-crit-i  cal 

Requirements: 

(Bl): 

Identify  all  resources  and  distinct  address  spaces  to  be  protected  by 
the  TCB,  including  the  TCB  code  and  data  structures 


(B2) : 


Identify  all  ways  in  which  a  user  can  interface  with  the  TCB  by 
identifying  all  elements  of  the  TCB  and  identifying  the  user  interface 
to  each 

Design: 

(C2) : 


Establish  method  of  isolating  resources  to  be  protected  by  the  TCB 


(Bl): 


Establish  a  mode  for  protecting  each  resource  and  distinct  address 
space  within  the  TCB 


(B2) : 


Establish  the  user  interface  for  the  TCB 


3. 3. 3. 1.2  System  Integrity 
(Cl): 

c  Hardware  and/or  software  features  shall  be  provided  that  can  be  used  to 
periodically  validate  the  correct  operation  of  the  on-site  hardware  and 
firmware  elements  of  the  TCB 

Requirements: 

(Cl): 


Identify  hardware  and  firmware  elements  of  the  TCB  to  be  validated 
Determine  validation  criteria  for  testing  each  element  of  the  TCB 
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Leterrune  *_nt  appropriate  mter.a.  at  wrucr  validct.o: 
Hardware  : .  :tnware  snoulc  tahe  pi  act 


Design: 

(Cl): 


Establish  a  method  for  testing  each  criterion  for  each  element  of  the 
TCB 

3. 3. 3. 1.3  Oovert  Channel  Analysis 

o  System  developer  shall  conduct  a  thorough  search  for  oovert  channels 
and  make  a  determination  of  the  maximum  bandwidth  of  each  identified 
channel 

As  mentioned  in  the  Covert  Channel  Analysis  section  of  the  Class  B2  TCB 
discussion,  this  analysis  is  performed  by  the  system  developer  and  requires 
no  software  development.  As  such,  no  discussion  of  this  topic  is  necessary. 
It  is  important,  however,  to  note  that  in  the  development  of  a  Class  B3  TCB, 
the  search  performed  by  the  system  developer  is  for  all  covert  channels. 
The  scope  of  the  search  is  expanded  from  that  of  the  Class  B2  TCB,  because 
covert  channels  include  L_>th  covert  storage  channels  and  covert  timing 
channels. 


3. 3. 3. 1.4  Trusted  Facility  Management 
(B2) : 

o  TCB  shall  support  separate  operator  and  administrator  functions 
o  Functions  performed  in  the  role  of  security  administrator  shall  be 
identified 

o  ADP  system  administrative  personnel  shall  only  be  able  to  perform 
security  administrator  functions  after  taking  a  distinct  auditable 
action  to  assume  the  security  administrator  role  on  the  ADP  system 
o  Non-security  functions  that  can  be  performed  in  the  security 
adminstration  role  shall  be  limited  strictly  to  those  essential  to 
performing  the  security  role  effectively 
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Requirements: 

(B2) : 

Identify  all  functions  to  be  performed  by  the  operator  and 
adniinistrator 

massify  admin  iterator  functions  as  system  or  security  functions 

The  major  distinction  between  Trusted  Facility  Management  in  a  Class  B2  TCB 
and  Trusted  Facility  Management  in  a  Class  B3  TCB  deals  wim  the  level  of 
protection  for  the  administrative  functions.  In  Class  C2.  all  of  these 
"functions,  including  system  administration  and  security  administration,  are 
all  at  the  same  level  of  protection.  In  a  Class  B3  TCB,  although  these 
functions  are  all  accessible  via  the  administration  function,  a  special 
auditable  action  is  required  to  access  the  security  administration 
functions.  To  develop  the  administrator  function  properly,  an  additional 
requirement  is  necessary.  In  addition  to  identifying  all  functions  to  be 
performed  by  the  administrator,  each  identified  function  must  be  classified 
as  to  whether  it  is  a  system  function  or  a  security  function. 

Design: 

(B2) : 

Establish  a  mechanism  for  the  proper  operation  of  each  of  the  functions 
for  the  operator  and  each  of  the  functions  for  the  administrator 


3. 3. 3. 1.5  Trusted  Recovery 

o  Procedures  and/or  mechanisms  shall  be  provided  to  assure  that,  after  an 
ADP  system  failure  or  other  discontinuity,  recovery  without  a 
protection  cotnpramise  is  obtained 

Requirements: 

Identify  a  means  far  assuring  that  system  failure  will  not  result  in  a 
protection  copprcmise 

To  properly  determine  the  requirements  for  the  trusted  recovery  of  a  Class 
B3  TCB,  a  means  must  be  identified  for  assuring  that  after  an  ADP  system 
failure  or  other  discontinuity,  system  recovery  can  be  achieved  without 
conprcmising  the  security  protection  of  the  TCB.  Wien  such  a  failure 
occurs,  all  accesses  to  the  TCB,  especially  through  communication  channels 
and  device  I/O,  are  securely  terminated.  During  system  recovery  the  state 
of  accesses  to  the  TCB  must  be  checked  to  ensure  that  no  unauthorized  access 
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ls  possible.  Thus ,  the  integrity  of  tne  security  of  the  TCE  must  u 
maintained  uorirc  systac  recovery  as  we...  as  curing  norma..  systeir  operation 

Design: 

-  Establish  a  mechanism  for  recovering  from  system  failure  in  a  trusted 
marmpr 

The  design  of  a  mechanism  for  trusted  recovery  from  an  ADP  system,  failure 
must  satisfy  the  requirements  stated  above.  It  must  provide  a  means  for  the 
system  to  completely  maintain  the  integrity  of  the  TCB’s  security  during 
failure  and  system  recovery  so  that  no  unauthorized  access  (e.g. ,  through 
covert  channels)  to  the  TCB  is  allowed  during  these  vulnerable  times. 

3. 3. 3. 2  Life-<ycle  Assurance 

3. 3. 3. 2.1  Security  Testing 


(Cl): 

o  Security  mechanisms  of  the  ADP  system  shall  be  tested  and  found  to  work 
as  claimed  in  the  system  documentation 


(Bl) : 

o  Team  of  individuals  who  thoroughly  understand  the  specific 
implementation  of  the  TCB  shall  subject  its  design  documentation , 
source  code,  and  object  code  to  thorough  analysis  and  testing.  The 
team's  objectives  will  be  (1)  to  uncover  all  design  and  implementation 
flaws  that  would  permit  a  subject  external  to  the  TCB  to  read,  change, 
or  delete  data  normally  denied  under  the  mandatory  or  discretionary 
security  policy,  and  (2)  to  assure  that  no  subject  is  able  to  cause  the 
TCB  to  enter  a  state  such  that  it  is  unable  to  respond  to 
communications  initiated  oy  other  users 
o  TCB  shall  be  found  resistant  to  penetration 

(B2) : 

o  All  discovered  flaws  shall  be  corrected  and  the  TCB  retested  to 
demonstrate  that  they  have  been  eliminated  and  that  new  flaws  have  not 
been  introduced 

o  Testing  shall  demonstrate  that  the  TCB  implementation  is  consistent 
with  the  descriptive  top-level  specification 
o  No  design  flaws  ard  no  more  than  a  lew  correctable  implementation  flaws 
may  be  found  dm-ing  testing,  and  there  shall  be  reasonable  ccnfidksnce 
that  few  ranain 
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(Cl) 


Identify  security  protection  mechanisms  of  the  TCB  to  be  tested 
Design: 

(Bl): 


Establish  means  of  testing  each  security  protection  mechanism  in  a 
manner  consistent  with  the  stringent  requirements  detailed  in  the  TCSEC 

Ooding: 

(Cl): 


Use  prudently  placed  debug  statements  to  allcw  the  tester  to  monitor 
operation  of  the  security  uechanisms 


3. 3. 3. 2. 2  Design  Specification  and  Verification 
(B2) : 

o  Formal  model  of  the  security  policy  supported  by  the  TCB  shall  be 
maintained  that  is  proven  to  be  consistent  with  its  axioms 
o  A  descriptive  top-level  specification  (DUS)  of  the  TCB  shall  be 
maintained  that  completely  and  accurately  describes  the  TCB  in  terms  of 
exceptions,  error  messages,  and  effects.  It  shall  be  shown  to  be  an 
accurate  description  of  the  TCB  interface, 
o  A  convincing  argument  shall  be  given  that  the  COTS  is  consistent  with 
the  model 

Design: 

(Bl): 


Identify  the  model  to  be  utilized 

Prove  consistency  between  design  and  the  model 
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3.3.3.?.?  Confiouratior:  Managemsnt 
(B2) : 

o  A  configuration  management  system  shall  be  in  place  that  maintains 
control  of  changes  to  the  descriptive  top-level  specification,  other 
design  data,  implementation  documentation,  source  code,  the  running 
version  of  the  object  code,  and  test  fixtures  and  documentation 
o  The  configuration  management  system  shall  assure  a  consistent  mapping 
among  all  documentation  and  code  associated  with  the  current  version  of 
the  TCB 

o  Tools  shall  be  provided  for  generation  of  a  new  version  of  the  TCB  from 
source  code  and  for  comparing  a  newly  generated  version  with  the 
previous  TCB  version  in  order  to  ascertain  that  only  the  intended 
changes  have  been  made  in  the  code  that  will  actually  be  used  as  the 
new  version  of  the  TCB 


3.3.4  Documentation 
(Cl): 

Documentation  is  an  important  part  of  the  software  development  process.  It 
aids  users  who  are  not  familiar  with  the  system  in  learning  how  to  use  the 
system  correctly.  It  aids  support  programmers  in  testing  the  system  to 
ensure  that  a  modification  has  not  had  a  negative  impact  on  the  system. 
This  is  especially  important  when  developing  a  TCB,  because  the  security  of 
the  system  is  of  the  utmost  importance.  While  this  is  true,  no  special 
consideration  needs  to  be  given  to  the  development  of  the  documentation  for 
the  TCB.  The  documentation  must  be  developed  to  meet  all  requirements  set 
forth  in  the  TCSEC,  and  must  be  complete  and  up-to-date;  however,  this  is 
not  particular  to  this  development  and  requires  no  further  discussion. 


3. 3. 4.1  Security  Features  User's  Guide 
(Cl): 

o  Single  summary,  chapter,  or  manual  in  user  documentation  shall  describe 
the  protection  mechanisms  provided  by  the  TCB,  guidelines  on  their  use, 
and  hew  they  interact  with  one  another 
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? .  3 . 4 . 2  Trusted  Facility’  Manual 
(Cl): 

o  Manual  addressed  to  the  ADP  system  administrator  shall  present  cautions 
about  functions  and  privileges  that  should  be  controlled  when  running  a 
secure  facility 


(C2) : 

o  The  procedures  for  examining  and  maintaining  the  audit  files,  as  well 
as  the  detailed  audit  record  structure  for  each  type  of  audit  event, 
shall  be  given 


(Bl): 

o  Manual  shall  describe  the  operator  and  administrator  functions  related 
to  security,  to  include  changing  the  security  characteristics  of  a  user 
o  Manual  shall  provide  guidelines  on  the  consistent  and  effective  use  of 
the  protection  features  of  the  system,  hew  they  interact.,  hew  to 
securely  generate  a  new  TCB,  and  facility  procedures,  warnings,  and 
privileges  that  need  to  be  controlled  in  order  to  operate  the  facility 
in  a  secure  manner 


(B2) : 

o  TCB  modules  that:  contain  the  reference  validation  mechanism  shall  be 
identified 

o  Procedures  for  secure  generation  of  a  new  TCB  from  source  after 

modification  of  any  modules  in  the  TCB  shall  be  described 

o  Manual  shal  1  include  the  procedures  to  ensure  that  the  system  is 
initially  started  in  a  secure  manner 

o  Procedures  shall  also  be  included  to  resume  secure  system  operation 
after  any  lapse  in  system  operation 

3 . 3 . 4 . 3  Test  Documentation 

(Cl): 

o  System  developer  shall  provide  to  the  evaluators  a  document  that 

describes  the  test  plan,  test  procedures  that  shew  hew  the  security 
mechanisms  were  tested,  and  results  of  the  security  mechanisms' 
functional  testing 
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o  Documentation  shall  include  results  of  testing  of  effectiveness  of  the 
methods  used  to  reduce  covert  channel  bandwidths 

3. 3. 4. 4  Design  Documentation 
(Cl): 

o  Documentation  shall  be  available  that  provides  a  description  of  the 
manufacturer's  philosophy  of  protection  and  an  explanation  of  hew  this 
philosophy  is  translated  into  the  TCB 


(82) : 

o  The  interfaces  between  the  TCB  modules  shall  be  described 
o  A  formal  description  of  the  security  policy  model  enforced  by  the  TCB 
shall  be  available  and  proven  to  be  sufficient  to  enforce  tire  security 
policy 

o  Specific  TCB  protection  mechanisms  shall  be  identified  and  an 
explanation  given  to  shew  that  they  satisfy  the  model 
o  The  DTLS  shall  be  shown  to  be  an  accurate  description  of  the  TCB 
interface 

o  tcb  i -ny>T ^mentation  fj.g.,  hardware,  firmware,  and  software/  shall  be 
informally  shown  to  be  consistent  with  the  ITUS 
o  The  elements  of  the  DUS  shall  be  shown,  using  infoosal  techniques,  to 
correspond  to  the  elements  of  the  TCB 

o  Documentation  shall  describe  hew  tire  TCB  implements  the  reference 
monitor  concept  and  give  an  explanation  why  it  is  tamper  resistant, 
cannot  be  bypassed,  and  is  correctly  implemented 
o  Documentation  shall  describe  hew  the  TCB  is  structured  to  facilitate 
testing  ana  to  enforce  least  privilege 
o  Documentation  shall  also  present  the  results  of  covert  channel  analysis 
and  trie  tradeoffs  involved  in  restricting  the  channels 
c  All  auditable  events  that  may  be  used  in  the  exploitation  of  known 
covert  storage  channels  shall  be  identified 
o  The  bandwidths  of  known  covert  storage  channels,  the  use  of  which  is 
not  detectable  by  the  auditing  mechanisms,  shall  be  provided 
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1.1  BacKoround 

One  intent  of  this  appendix  is  to  identify  benefits  of  using  Ada  in  the  software 
development  of  TCB  systems.  These  benefits  include  Ada's  assets  in  the 
application  of  sound  software  engineering  principles,  such  as  data  abstraction, 
information  hiding,  modularity,  and  localization.  Also  included  among  the 
benefits  are  such  Ada  constructs  as  strong  data  typing,  packages,  subprograms, 
and  tasks.  Also  the  benefits  of  using  tools  in  the  develpment  of  Ada  language 
software  are  discussed. 

Anotiier  intent  of  this  appendix  is  to  identify  and  categorize  potential 
deterrents  of  using  Ada  in  the  software  development  of  TCB  systems.  These 
include  shortcomings  inherent  to  programming  languages  in  general;  shortcomings 
unique  to  the  Ada  language. 

This  appendix  is  meant  to  stand  alone;  however,  a  familiarity  with  the  TCSEC  is 
recommended  to  be  better  able  to  use  this  appendix.  Also,  familiarity  with  the 
Ada  programming  language  is  helpful. 


1.2  Format 

This  appendix  consists  of  four  sections.  The  first  section  is  an  introduction 
which  consists  of  background  information  and  definitions  of  key  terms  that  appear 
in  this  report.  The  key  terms  section  includes  terms  found  in  the  glossary  of 
the  TCSEC,  the  Reference  Manual  for  the  Ada  Programming  language  (LRM)  [ ANSI/MI Lr- 
STD-1815A-1983] ,  and  the  IEEE  Standard  Glossary  of  Software  Engineering 
Terminology  [IEEE  1983].  Sections  2.0  and  3.0  address  the  benefits  and 
deterrents  issues  in  two  ways.  First,  Section  2.0  focuses  on  the  following 
issues:  (1)  Benefits  of  using  Ada  in  Developing  TCB  systems,  (2)  Potential 
deterrents  to  using  Ada  in  developing  TCB  systems,  (3)  Shortcomings  inherent  to 
programming  languages  in  general  in  developing  TCB  systems,  (4)  Shortcomings 
unique  to  the  Ada  language  in  developing  TCB  systems,  (5)  Benefits  of  using  tools 
for  developing  Ada  software  for  TCB  systems.  Section  3.0  presents  these  issues 
in  the  context  of  a  mapping  of  Ada  usage  to  generalized  TCB  criteria.  In 
particular,  class  B3  as  defined  in  the  TCSEC  is  used  as  a  template  for  the 
generalized  TCB  criteria.  Ada  constructs  and  features  are  identified  that  may  be 
used  to  implement  TCB  functions  and  features.  Though  potential  problems  are 
identified  with  using  various  Ada  constructs  and  features,  this  is  not  meant  to 
imply  that  any  of  the  constructs  and  features  should  not  be  used;  only  that  tne 
security  of  the  TCB  must  not  be  ccrtpranised  when  ary  of  the  constructs  and 
features  are  used  in  the  implementation  of  the  TCB.  Section  4.0  consists  of  a 
summary  of  this  report  and  its  conclusions. 
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1.3  Kev  terms 

Several  key  words  appear  throughout  the  text  of  this  appendix.  These  words  have 

specific  meanings  within  the  context  of  certified  systems,  and  their  definitions 

are  presented  here.  These  definitions  are  taken  directly  from  the  TCSEC: 

Access  -  A  specific  type  of  interaction  between  a  subject  and  an  object  that 
results  in  the  flow  of  information  from  one  to  the  other. 

Audit  Trail  -  A  set  of  records  that  collectively  provide  documentary  evidence  of 
processing  used  to  aid  in  tracing  from  original  transactions  forward  to 
related  records  and  reports,  and/or  backwards  from  records  and  reports  to 
their  component  source  transactions. 

Covert  Channel  -  A  communication  channel  that  allows  a  process  to  transfer 
information  in  a  manner  that  violates  the  system's  security  policy. 

Data  -  Information  with  a  specific  physical  representation. 

Discretionary  Access  Control  -  A  means  of  restricting  access  to  objects  based  on 
the  identity  of  subjects  and/or  groups  to  which  they  belong.  The  controls 
are  discretionary  in  the  sense  that  a  subject  with  a  certain  access 
permission  is  capable  of  passing  that  permission  (perhaps  indirectly)  on  to 
any  other  subject  (unless  restrained  by  mandatory  access  control) . 

Mandatory  Access  Control  -  A  means  of  restricting  access  to  objects  based  on  the 
sensitivity  (as  represented  by  a  label)  of  the  information  contained  in  the 
objects  and  the  formal  authorization  (i.e.,  clearance)  of  subjects  to  access 
information  of  such  sensitivity. 

Object  -  A  passive  entity  that  contains  or  receives  information.  Access  to  an 
object  potentially  implies  access  to  the  information  it  contains.  Examples 
of  objects  are:  records,  blocks,  pages,  segments,  files,  directories, 
directory  trees,  and  programs,  as  well  as  bits,  bytes,  words,  fields, 
processors,  video  displays,  keyboards,  clocks,  printers,  network  nodes,  etc. 

Sensitivity  Tahoi  -  a  piece  of  information  that  represents  the  security  level  of 
an  object  and  that  describes  the  sensitivity  (e.g.,  classification)  of  the 
data  in  the  object.  Sensitivity  labels  are  used  by  the  TCB  as  the  basis  for 
mandatory  access  control  decisions. 

Subject  -  An  active  entity,  generally  in  the  form  of  a  person,  process,  or  device 
that  causes  information  to  flew  among  objects  or  changes  the  system  state. 
Technically,  a  process/damain  pair. 
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Trusted  Caputing  Base  (TCB)  -  The  totality  of  protection  mechanisms  within  £ 
computer  system  —  including  hardware  firmware,  and  software  —  the 
combination  of  which  is  responsible  for  enforcing  a  security  policy.  A  TCB 
consists  of  one  or  more  components  that  together  enforce  a  unified  security 
policy  over  a  product  or  system.  The  ability  of  a  TCB  to  correctly  enforce 
a  security  policy  depends  solely  on  the  mechanisms  within  the  TCB  and  on  the 
correct  input  by  system  administrative  personnel  of  parameters  (e.g. ,  a 
user's  clearance)  related  to  the  security  policy. 


Additional  Terms 

These  terms  are  included  because  they  appear  frequently  in  the  following  text. 

Pragma  -  A  compiler  directive.  That  is,  it  "is  used  to  convey  information  to 
the  compiler."  According  to  the  Ada  language  reference  manual  [ANSI/MIL- 
STD-1815A-1983] ,  the  predefined  pragmas  (Refer  to  Annex  B  in  this  manual  for 
descriptions)  "must  be  supported  by  every  implementation .  In  addition,  an 

implementation  may  provide  implementation-defined  pragmas,  which  must  then 
be  described  in  Appendix  F",  i.e. ,  the  appendix  on  implementation-dependent 
characteristics  that  the  Ada  compiler  vendor  must  provide  in  his  Ada 
language  reference  manual. 

Security  -  The  protection  of  computer  hardware  and  software  from  accidental  or 
malicious  access,  use,  modification,  destruction,  or  disclosure.  Security 
also  pertains  to  personnel,  data,  aaranunications,  and  the  physical 
protection  of  computer  installations  [IEEE  1983].  Specifically,  for  the 
purposes  of  this  report,  security  is  defined  by  the  criteria  in  the  TCSEC, 
i.e.,  a  given  security  problem  corresponds  with  a  specific  TCSEC  criteria. 

To  better  appreciate  the  viewpoint  of  this  appendix,  the  reader  is  advised  that 
the  word  "may"  is  used  frequently  to  avoid  incorrect  absolute  blanket  assertions. 
In  particular,  the  use  of  "may"  indicates  that  potential  security  risks  are 
subject  to  arise  when  using  the  various  Ada  (and  other  higher  order  language 
(HOL))  constructs  and  techniques.  That  is,  the  presence  and  severity  of  any 
given  security  risk  depends  on  hew  the  various  constructs  and  techniques  are 
implemented  and  the  context  in  which  they  are  used.  Therefore,  the  use  of  any 
given  construct  or  technique  may  caprcsnise  security,  depending  on  its 
implementation  and  the  context  of  its  use. 
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2.0  BENEFITS  AND  POTENTIAL  DETERRENTS  OF  USING  ADA  IN  DEVELOPING  TCB  SYSTEMS 

This  section  addresses  three  issues:  benefits  of  using  Ada,  shortccrriings  of  using 
higher  order  languages  (HOLs)  in  general  and  Ada  in  particular,  and  the  benefits 
of  using  system  development  tools.  Although  potential  problems  are  identified 
with  using  various  HOLs  and  Ada  features,  this  is  not  meant  to  imply  that  any  of 
the  features  should  not  be  used.  Rather,  the  security  of  the  TCB  must  not  be 
conpranised  when  any  of  the  constructs  and  features  are  used  in  the 
implementation  of  the-  TCB.  Similarly,  although  currently  available  system 
development  tools  have  their  limitations,  the  benefits  of  using  them  may  offset 
these  limitations,  especially  when  compared  with  not  using  any  tools. 

Though  this  report  does  not  advocate  abstaining  from  using  any  Ada  constructs,  it 
should  be  noted  that  each  of  them,  to  varying  degrees,  contributes  to  a  large  Ada 
runtime  library.  Eric  Anderson,  in  his  paper,  "Ada's  Suitability  for  Trusted 
Computer  Systems,"  proposes  the  extreme  view  of  minimizing  the  Ada  runtime 
library  for  the  security  kernel  as  a  primary  goal  itself,  because  its  size  may 
lend  itself  to  hiding  covert  channels  and  Trojan  horses.  This  problem  of  an 
excessively  large  Ada  runtime  library  is  in  addition  to  the  potential  deterrents 
associated  with  the  various  Ada  constructs  that  are  discussed  below. 

To  minimize  the  size  of  the  Ada  runtime  library  Eric  Anderson  proposes  the 
following  severe  restrictions  on  the  use  of  Ada  constructs  in  creating  the 
security  kernel:  not  allowing  use  of  any  dynamic  storage,  tasking,  exception 
handling,  any  Ada  standard  packages  other  than  STANDARD  and  SYSTEM;  and  limiting 
the  use  of  runtime  constraint  checking,  math  and  conversion  routines,  and 
representation  clauses.  Addressing  the  security  issues  associated  with  the  Ada 
runtime  library  are  beyond  the  scope  of  this  report.  Clearly,  though,  Ada 
runtime  library  security  issues  need  to  be  addressed  by  further  research. 
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2.1  Benefits  of  Using  Ada  in  Developing  TCB  Systems 

The  following  beneficial  features  are  available  in  the  Ada  programming  language. 

2.1.1  Data  Abstraction: 

Ada's  data  abstraction  mechanisms  are  well  suited  to  represent  the  data 
objects  in  a  system's  design,  namely,  that  of  a  TCB.  They  serve  the 
conceptual  manipulation  of  the  data  objects  in  a  relatively  high-level  of 
abstraction  without  regard  to  their  underlying  representation.  Ada  allows 
data  to  be  abstracted  with  abstract  data  types.  An  abstract  data  type  is  a 
construct  that  "denotes  a  class  of  objects  whose  behavior  is  defined  by  a 
set  of  values  and  a  set  of  operations"  [Booch  1987A,  p.613].  Ada's  two 
primary  features  that  promote  the  creation  of  abstract  data  types  are  its 
strong  data  typing  facilities  and  its  packaging  mechanism.  Strong  data 
typing  serves  to  isolate  data  types.  A  package  can  be  used  to  define  an 
abstract  data  type  by  encapsulating  its  underlying  data  types  and  the 
operations  associated  with  the  abstract  data  type.  Ada's  strong  data  typing 
facility  allows  the  creation  of  user-defined  types,  namely,  subtypes  and 
derived  types.  Using  Ada's  data  abstraction  techniques  aids  the 
representation  of  data  objects  in  the  problem  space  of  any  system,  including 
a  TCB.  "Abstraction  aids  in  the  maintainability  and  understandability  of 
systems  by  reducing  the  details  a  developer  needs  to  know  at  any  given 
level"  [Booch  1987B,  p.33].  Data  abstraction  enhances  understandability  by 
allowing  the  review  of  system  design  to  focus  on  high-level,  abstract  data 
elements  instead  of  smaller  component  parts.  This  increases  the 

understandability  of  both  the  design  and  the  code.  Thus,  this  sound 
software;  engineering  technique  can  promote  an  Ada  TCB  system's  design, 
implementation,  and  maintenance. 


2.1.2  Information  Hiding: 

Ada's  information  hiding  facilities  complement  its  data  abstraction 
capabilities.  Whereas  abstractions  extract  the  essential  details  of  a  given 
level,  "the  purpose  of  hiding  is  to  make  inaccessible  certain  details  that 
should  not  affect  other  parts  of  a  system"  [Ross,  Goodenough,  Irvine  1975, 
p.67] .  "Information  hiding  therefore  suppresses  how  an  object  or  operation 
is  implemented,  and  so  focuses  our  attention  on  the  higher  abstraction" 
[Booch  1987B,  p.33].  Two  Ada  constructs  that  are  well  suited  for 
implementing  information  hiding  are  packages  and  private  types.  "Packages 
can  be  used  to  hide  information  from  the  rest  of  the  program  while  making 
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that  implementation  details  of  each  package  can  be  changed  by  altering  only 
its  body,  and  that  the  rest  of  the  program  may  be  understood  without 
reference  to  these  details"  [Nissen  and  Wallis  1984,  p. 122] .  As  much  as 
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possible  of  the  implementation  detail  should  be  hidden  in  the  body  of  the 
package. 

Hiding  the  information  about  the  implementation  of  the  data  abstraction  of  a 
data  object  is  achieved  in  Ada  by  encapsulating  the  abstraction  in  a 
package,  i.e. ,  by  hiding  the  implementation  of  the  object  and  controlling 
access  to  the  object  so  as  to  encourage  and  enforce  the  abstraction.  This 
typically  is  done  with  the  use  of  private  types  and  limited  private  types. 
In  particular,.  Ada.'s  private  types  enable  the  focus  to  be  placed  on  higher- 
level  real-world  abstractions  rather  than  on  the  details  of  an 
implementation.  The  following  implicit  operations  may  be  performed  on 
private  types:  assignment,  tests  of  equality  and  inequality,  explicit  type 
conversion,  membership  tests,  type  qualification,  and  the  use  of  selected 
components  for  the  selection  of  any  of  the  private  type's  discriminant.  For 
limited  private  types,  though,  only  those  operations  defined  in  the 
corresponding  package  specification  are  allowed.  For  more  detailed 
information  on  private  types,  refer  to  the  Ada  LRM  [ANSI/MI]>STD-1815A- 
1983].  "Private  types  prevent  misuse  of  structures  by  users,  presenting 
them  only  with  the  abstract  operations  appropriate  for  the  abstractions 
involved"  [Nissen  and  Wallis  1984,  p.131]. 

An  example  of  using  Ada's  information  hiding  (and  data  abstraction)  would  be 
to  implement  a  package  that  defined  a  linked  list  structure.  Only  those 
details  required  by  a  user  of  the  linked  list  package  would  be  provided  in 
the  package  specification  (data  abstraction),  e.g. ,  the  operations  allowed 
on  the  linked  list.  The  implementation,  though,  of  the  linked  list  would  be 
hidden  inside  the  package  body.  The  user  of  the  package  does  not  need  to 
knew  hew  the  linked  list  is  implemented,  therefore,  information  on  its 
implementation  is  hidden  from  the  user. 

The  understandability  of  systems  is  enhanced  "when,  at  each  level  of 
abstraction,  we  permit  only  certain  operations  and  prevent  any  operations 
that  violate  our  logical  view  of  that  level"  [Booch  1987B,  p.33].  Hiding 
information  about  implementation  details  of  subprograms  in  package  bodies 
offers  various  benefits.  These  include  protecting  the  integrity  of  the 
subprograms  from  undue  alteration  by  user's  of  the  subprograms.  Also  it 
allows  a  user  of  the  subprograms  specified  in  the  package  specification  to 
think  in  a  higher  xevel  of  abstraction  rather  than  being  mired  in  the 
subprograms'  implementation  details.  Thus,  this  sound  software  engineering 
technique  can  promote  an  Ada  TCB  system's  design,  implementation,  and 
main  tenar  ice. 
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2.1.3  Modularity  and  localization: 

Modularity  provides  the  mechanism  for  collecting  logically  related 
abstractions.  It  deals  with  how  the  structure  of  an  object  can  make  the 
attainment  of  seme  purpose  easier.  Modularity  is  purposeful  structuring, 
which  is  usually  achieved  in  a  large  system  by  deccrposing  the  system  top- 
down  with  modules  that  are  either  functional  (procedure-oriented)  or 
declarative  (object-oriented)  [Booch  1987B,  p.34].  It  is  composed 
preferably  of  existing  reusable  battcm-up  software  components.  'mis 
structuring,  should  be  performed  to  minimize  the  coupling  between  modules 
(i.e. ,  minimizing  dependencies  between  modules)  and  to  strengthen  the 
cohesion  within  modules  (i.e.,  the  components  of  a  given  module  are 
functionally  and  logically  dependent)  [Booch  1987B,  p.34]. 

Localization  is  the  collecting  of  logically  related  computational  resources 
in  one  physical  module  that  is  sufficiently  independent  of  other  modules. 
Localization  thus  helps  to  create  modules  that  exhibit  loose  coupling  and 
strong  cohesion. 

The  principles  of  modularity  and  localization  directly  support 
modifiability,  and  understandability  [Booch  1987B,  p.34].  Any  given  module 
should  be  understandable  and  relatively  independent  of  other  modules. 
Design  decisions  localized  in  given  modules  limit  the  effects  of  a 
modification  to  a  small  set  of  modules.  This  directly  supports  TCB 
development  in  two  ways.  First,  all  the  code  related  to  a  particular 
purpose,  e,g. ,  discretionary  access  control,  is  localized  which  aids  in  the 
understanding  the  implementation.  Also,  a  change  in  the  inplmentation 
should  not  propagate  beyord  the  local  modules.  Thus,  the  use  of 
modularization  that  limits  the  interconnections  among  program  modules,  and 
the  localizing  of  logically  related  resources  into  modules  are  sound 
software  engineering  techniques  that  can  promote  an  Ada  TCB  system's  design, 
implementation,  and  maintenance. 


2.1.4  Dynamic  Storage  with  Access  Types: 

Dynamic  storage  is  a  pool  of  memory,  or  heap,  that  is  used  for  storing  data 
whose  demand  for  memory  varies  during  program  execution.  Despite  the 
problems  associated  with  dynamic  storage  and  Ada's  access  types  discussed 
below,  it  is  a  useful  mechanism  that  can  provide  a  convenient  and  flexible 
means  of  managing  memory  when  the  need  for  memory  is  constantly  changing. 
Though  Ada  also  provides  an  automatic  garbage  collection  facility,  this 
management  of  dynamic  storage  may  result  m  cats  being  left  m  the  memory 
heap  when  the  memory  is  deallocated. 


The  security  of  a  TCB's  dynamically  stored  data  that  is  about  to  be 
collected  by  this  garbage  collection  can  be  protected  by  deleting  the  data 
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just  before  it  is  collected  as  garbage.  That  is,  sensitive  data  that  may  be 
accessed  by  an  unauthorized  user  or  subject  must  be  removed  from  memory 
before  the  memory  is  deallocated.  Also  memory  should  be  scrubbed  just 
before  it  is  dynamically  allocated  with  Ada's  new  statement.  Note  that 
these  additional  checks  will  impinge  on  system  performance.  It  would  be 
desirable  to  include  in  the  next  revision  of  Ada  (Ada9x)  a  predefined  pragma 
that  directs  Ada  compilation  to  include  code  to  scrub  dynamically  allocated 
and  deallocated  memory  after  acquiring  it  from  and  returning  it  to  the  heap 
respectively. 


2.1.5  Concurrent  Programming  with  Tasking: 

In  contrast  to  other  languages  Ada  incorporates  its  concurrent  programming 
mechanism,  namely,  tasking,  as  an  integral  part  of  its  definition. 
Concurrent  processes,  in  particular,  tasks,  are  processes  that  may  execute 
in  parallel  on  multiple  processors  or  independently  scheduled  processes  on  a 
single  processor.  That  is,  they  involve  the  simultaneous,  or  timeshared, 
execution  of  processes.  Tasks  may  interact  with  each  other,  and  one  task 
may  suspend  execution  pending  receipt  of  information  from  another  task  or 
the  occurrence  of  an  external  event.  Despite  the  problems  associated  with 
concurrent  programming  and  Ada's  tasking  discussed  below,  it  is  a  useful 
mechanism  that  likely  is  required  for  the  effective  implementation  of  a  TCB 
system.  Safeguards,  as  required  by  a  TCB's  class  requirements,  in 
communication  between  tasks  must  be  enforced  in  the  TCB  system,  e.g. ,  with 
discretionary  access  controls  (e.g. ,  access  control  lists)  and/or  mandatory 
access  controls  (e.g.,  sensitivity'  labels).  Communications  between  tasks 
(e.g.,  rendezvous)  should  be  logged  in  the  audit  trail. 


2.1.6  Compilation  of  Specifications : 

Ada  provides  the  ability  to  compile  package  and  subprogram  specifications 
during  the  design  stage  of  system  development.  This  aids  in  the  early 
checking  of  interfaces  between  packages,  and  with  parameter  consistency 
between  subprograms  in  the  same  package.  The  data  structures  are  declared 
in  the  specifications,  and  consistent  use  of  data  types  can  be  automatically 
checked  during  design.  The  use  of  Ada's  capability  to  compile  package  and 
subprogram  specifications,  therefore,  allows  early  checking  of  a  system's 
desing  and  interfaces  before  the  designers  and  implementors  get  mired  in 
implementation  details.  Thus,  the  quality  of  the  TCB  is  promoted  by  using 
specification  compilation. 


2.1.7  Reusable  Code: 

The  implementation  of  an  Ada  TCB  system  can  be  aided  with  the  reuse  of 
evaluated  code  that  has  been  demonstrated  to  sufficiently  satisfy  the 
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security  class  of  the  given  TCB.  Ada's  generic  units  are  helpful  in 
creating  reusable  cede.  "Gerserics  provide  a  powerful  means  by  which  a 
program  may  be  '  factorised 1  in  order  to  shorten  code,  and  reduce  incidence 
of  errors,  by  avoiding  redefining  items  which  appear  in  several  places  in 
the  program"  [Nissan  and  Wallis  1984,  p.181] .  When  cede  is  reused  the 
Timber  of  errors  in  the  cede  is  reduced  because  errors  in  such  code  are 
fixed  when  they  are  identified.  Additional  time  and  effort  is  required 
during  the  design  phase  of  developing  reusable  code  for  a  TCB  system.  Ihe 
additional  time  and  effort  will  pay  for  itself  when  the  resulting  reusable 
code  is  used  in  multiple  instances  in  the  current  TCB  and  future  TCBs. 
Thus,  the  reuse  of  evaluated  code  is  a  sound  software  engineering  technique 
that  can  promote  the  efficient  production  of  an  Ada  TCB  system's  design, 
implementation,  and  maintenance. 


2.1.8  Standardization  and  Portability: 

Because  Ada  is  standardized  (by  the  Department  of  Defense  (DoD) ) ,  no  subsets 
or  supersets  of  Ada  are  all  wed.  This  standardization  is  assured  by  the 
DqD's  process  of  validation  of  Ada  compilers.  Before  any  compiler  can  be 
used  on  a  DoD  contract,  it  must  be  validated  by  passing  a  series  of  tests  to 
ensure  that  it  implements  the  LRM  [ANSI/KrL^STD-1815A~1983  ]  precisely.  This 
aids  the  portability  of  Ada  software  among  different  types  of  computers.  In 
particular,  an  Ada  TCB  system  is  more  lilcely  to  be  easier  to  port  between 
two  different  types  of  computers  than  if  the  TCB  were  developed  in  another 
language. 


2 . 2  Potential  Deterrents  to  Using  Ada  in  Developing  TCB  Systems 


2-2.1  Shortcomings  Inherent  to  PrcgrammiiXT  languages  in  General  in  Developing 
TCB  Systems 


The  following  features  are  typically  available  in  programming  languages.  Their 
use  poses  potential  deterrents  to  the  security  of  TC3  systems. 


2. 2. 1.1  Static  Storage: 

Static  storage,  such  as  local  variables  and  arrays,  are  typically  provided 
in  programming  languages.  When  a  portion  of  static  storage  is  no  longer 
needed  during  the  execution  of  a  program,  it  may  still  contain  data  to  which 
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static  storage,  that  is  no  longer  needed,  should  be  scrubbed. 
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2. 2.1. 2  Dynamic  Storac;t: 

Dynamic  storage,  as  discussed  above,  is  a  convenient  way  of  managing  a  given 
system's  continually  varying  demands  for  memory.  Dynamic  storage  is 
typically  used  to  implement  such  constructs  as  linked  lists  and  queues. 
This  introduces  the  possibility  that  sensitive  data  may  be  accessed  by  an 
unauthorized  user  or  subject  when  it  has  not  been  removed  from  newly 
allocated  or  deallocated  memory. 


2.2. 1.3  Input  and  Output: 

For  any  TCB  that  has  input  and  output  capabilities,  it  must  not  allow  an 
unauthorized  user  or  subject  to  gain  access  to  the  TCB  and  its  date.  For 
example,  users  must  be  prevented  from  accessing  disk  files  or  tapes  that 
they  are  not  authorized  to  access.  Also,  the  use  of  security7  sensitive 
terminals  must  be  restricted  to  those  users  who  have  authorization  to  use 
the  terminals.  The  security  of  the  TCB's  input  and  output  functions  should 
be  provided  with  discretionary  access  controls  (e.g. ,  access  control  lists) 
and/or  mandatory  access  controls  (e.g. ,  sensitivity  labels) .  All  inputs  to 
and  outputs  from  a  TCB  should  be  logged  in  the  audit  trail. 


2. 2. 1.4  Global  Variables: 

Global  vaiiables  (or  partially  global  variables,  e.g.,  in  FORTRAN  COMMON 
blocks)  ace  a  clement  means  oi*wpassing  data  between  different  parts  of  "2 
system.  The  use  of  global  variables  causes  difficulty  in  tracing 
modifications  to  the  variables.  Thus,  the  security  of  the  data  is  more 
difficult  to  regulate  in  a  TCB. 


2. 2. 1.5  Concurrent  Processing: 

As  discussed  above,  concurrent  processing  involves  the  simultaneous,  or 
timeshared,  execution  of  processes.  The  communications  between  the 
concurrent  processes  may  allow  the  introduction  of  covert  channels.  If 
multiple  processes  are  executing  concurrently,  then  one  process  could  detect 
the  extent  of  demands  being  placed  on  system  resources  by  the  system's 
responsiveness  to  the  process's  demands.  For  exanple,  a  process  might  be 
able  to  execute  a  series  of  subprograms  in  a  given  amount  of  time  when  it  is 
the  only  process  executing.  The  amount  of  time  to  execute  the  same  set  of 
subprograms  might  be  much  greater  when  several  processes  are  executing.  By 
monitoring  the  time  required  to  execute  its  own  subprograms,  this  process 
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of  covert  channel  is  heightened  by  concurrent  processing,  the  increase  in 
performance  warrants  that  concurrence  be  used  with  caution  rather  than  be 
totally  avoided.  The  security  of  communications  between  concurrent 
processes  should  be  managed  with  appropriate  discretionary  access  controls 
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(e.g.,  access  control  lists)  and/or  rrvimatory  access  controls  (e.g., 
sensitivity  labels) .  Communications  between  tasks  (e.g.,  rendezvous)  should 
be  logged  in  ‘die  audit  trail. 


2. 2. 1.6  Go  Tto  Statements: 

Go  To  statements  provide  the  means  for  a  program  to  transfer  control ,  in  an 
unstructured  manner,  of  its  operation  elsewhere  in  the  program,  iue  larger 
the  module,  the  more  potential  problems  that  Go  To  statements  .;an  present.. 
In  particular,  undesired  redirection  of  program  execution  xray  be  irscrted 
and  be  hard  to  track.  Because  this  transfer  of  control  may  b^  unregulated, 
ensuring  the  security  of  a  TCB  system  is  very  difficult,  Also,  ,<rost  HDIs, 
such  as  Ada,  provide  more  structured  control  structures  (e.g. .  fot  an.'.  while 
loops)  that  make  using  Go  To  statements  unnecessary. 

Example:  This  example  illustrates  unstructured  transfer  of  control  of 
program  execution  by  Go  To  statements. 

«  BackwardJLabol  » 

—  ...  Many  lines  of  code! 


goto  Forward_Label ; 


goto  Backward_Iabel ; 

—  ...  Many  .lines  of  code! 
«  Forward  Label  » 


2.2. 1.7  Interrupts: 

Interrupts  provide  asynchronous  means  of  altering  program  execution  so  that 
an  external  event  can  be  handled  by  the  system.  This  may  allow  the  handling 
of  an  external  event  so  that  an  unauthorized  user  or  subject  is  able  to  gain 
access  to  a  TCB  and  its  data.  Interrupts  should  be  managed  with 
discretionary  access  controls  (e.g.,  access  control  lists)  and/or  mandatory 
access  controls  (e.g. ,  sensitivity  labels) .  Interrupts  should  be  monitored 
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2. 2. 1.8  Lack  of  Modularity: 

A  primary  advantage  to  modular  systems  is  increased  understandability?  the 
primary  problem  with  a  lack  of  modularity  is  a  lack  of  understandability. 
Failure  to  adequately  modularize  a  TCB's  implementation  introduces  several 
problems  in  its  development  and  maintenance.  In  particular,  lack  of 
modularity  causes  the  system's  design  and  implementation  to  be  less 
understandable  because  the  high-level  abstraction  aspects  of  the  system  are 
obscured  by  the  exorbitant  amount  of  details  in  large  modules.  This  lack  of 
understandability  has  an  adverse  effect  on  testing,  because  not  all  of  the 
module's  functions  and  subfunctions  can  be  easily  identified  and  then 
tested.  Also,  lack  of  modularity  complicates  testing  because  the  typically 
greater  number  of  possible  logical  paths  (i.e. ,  transfers  of  control  of 
program  execution)  in  large  modules  cause  them  to  be  more  difficult  to  test 
thorouglily  than  small  modules,  which  have  few  possible  logical  paths.  This 
testing  is  further  complicated  by  the  use  of  Go  To  statements  in  large 
modules.  A  lack  of  modularity  has  a  great  adverse  effect  on  maintainability 
also.  Because  a  large  module  cannot  be  as  well  understood  as  a  smaller 
module,  any  ripple  effect  of  a  change  to  the  module  will  be  very  difficult 
to  detect  and  control. 


2.2.2  Shortcomings  Unique  to  the  Ada  language  in  Developing  TCB  Systems 

This  section  details  how  particular  constructs  and  features  that  may  be 
detrimental  to  the  development  of  TCB  systems  are  implemented  in  Ada.  Although 
these  constructs  and  features  introduce  the  potential  for  circumventing  security 
attributes,  their  use  may  at  times  be  necessary.  Also,  of  concern  is  the  effect 
when  multiple  features  in  this  list  are  used  together.  Such  interactions  are 
discussed  belcw  with  appropriate  constructs  and  features.  These  concerns  will  be 
addressed  in  the  programming  guidelines. 


.2.2.1  Static  Storage: 

Static  storage  is  a  portion  of  memory  that  is  set  aside  at  compile  time  and 
whose  size  dees  not  change  during  program  execution.  Objects  of  most  Ada 
data  types  use  static  storage.  Statically  stored  data,  like  that  in  an 
array,  can  generally  be  accessed  more  efficiently  than  data  stored 
dynamically  in  data  structures  consisting  of  access  types.  This  is  offset 
by  their  potentially  inefficient  use  of  memory;  this  is  particularly  true  of 
arrays.  It  would  be  desirable  to  include  in  the  next  revision  of  Ada 
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that  scrubs  memory  that  is  local  to  a  subprogram  or  package  just  before  the 
scope  of  the  subprogram  or  package  is  left  during  program  execution,  i.e., 
just  before  the  visibility  of  the  static  (or  dynamic)  memory  is  lost.  These 
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conflicting  needs,  efficient  execution  versus  efficient  use  of  memory,  are 
particularly  important  for  large  data  structures. 


2. 2. 2. 2  Dynamic  Storage  with  Access  Types: 

Access  types  are  used  in  Ada  to  implement  dynamic  storage  constructs,  like 
linked  lists  and  queues.  Thus  Ada  also  is  subject  to  the  same  problems  with 
securely  handling  dynamic  storage  that  are  associated  with  other  languages. 
"An  implementation  may  (but .  need  not)  reclaim  the  storage  occupied  by  an 
object  created  by  an  allocator,  once  this  object  has  become  inaccessible" 
[ANSI/MIIr-STD-1815A-1983] . 

In  addition,  Ada  has  the  pragpna  CONTROLLED,  which  "specifies  that  automatic 
storage  reclamation  must  not  be  performed  for  objects  designated  by  values 
of  the  access  type,  except  upon  leaving  the  innermost  block  statement, 
subprogram  body,  or  task  body  that  encloses  the  access  type  declaration,  or 
after  leaving  the  main  program"  [ANSI/MIL-STD-1815A-1983] .  The  use  of  this 
pragma  may  allow  unauthorized  access  to  dynamic  storage  that  is  yet  to  be 
deallocated.  Also,  "if  an  object  or  one  of  its  subcomponents  belongs  to  a 
task  type,  it  is  considered  to  be  accessible  as  long  as  the  task  is  not 
terminated".  Ibis  presents  the  possibility  that  unauthorized  access  to 
dynamic  storage  may  be  available  between  tasks. 


2. 2. 2. 3  Acticaticr!  Records 

When  program  execuition  leaves  the  scope  of  a  library  unit,  the  memory 
containing  its  data  is  returned  to  the  heap  without  being  scrubbed. 


2. 2. 2. 4  Global  Variables: 

"Global  variables"  may  be  implemented  in  Ada  either  in  a  package 
specification  or  a  subprogram  specification  or  used  as  shared  variables 
associated  with  tasks  (which  are  established  with  the  pragma  SHARED) .  The 
primary  advantage  of  using  global  and  shared  variables  is  that  some 
efficiency  in  data  transfer  within  the  program  is  typically  introduced. 
This  advantage  is  almost  always  offset  by  the  problems  caused  by  lasing 
global  and  shared  variables.  Using  global  variables  in  Ada  poses  problems 
similar  to  using  them  in  ether  languages,  as  discussed  above.  Ensuring  the 
security  of  data  "shared"  among  tasks  is  particularly  difficult  because  the 
flew  of  program  control  is  harder  to  trace  when  tasking  is  involved. 
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incorporates  global  or  shared  variables. 

Exanple:  This  example  illustrates  global  variable  scope/visibility  deterrent 
in  a  package  specification.  That  is,  any  package  or  subprogram 


B-17 


appjldd:  e 

Benefits  of  and  Potential  Deterrents  t; 
bsins  Ada  m  Developing  Systems 


that  withs  package  Highl  y_Visible_Package  can  access  and  thus 
modify  Global_ACL_Variables  in  a  manner  that  is  difficult  to  trace. 

with  AccessjCtontrol_List JTypes_Package  ; 
package  Highly_Visible_Package  is 

Global_ACL_Variables  :  Access_Control_List_Types_Package . 

Named_Ob j  ect_Reoord_Type ; 


end  Highly_Visible_Package; 


2. 2. 2. 5  Concurrent  Progranming  with  Asking: 

Tasking  is  Ada’s  means  of  implementing  concurrent  programming.  Tasks  and 
entries  have  three  attributes  as  specified  in  the  IFM:  T!  CALLABLE, 
T'TERMINATED,  and  E'CXXJNT.  The  use  of  these  dynamic  attributes  enables  the 
passing  of  information  in  a  manner  that  is  difficult  to  ocnprehend.  Their 
use  may,  therefore,  open  covert  channels.  The  communications  between  tasks 
may  also  allow  the  introduction  of  covert  channels.  In  addition,  a  tasking 
implementation  may  introduce  the  problems  with  dynamic  storage  and  global 
variables  discussed  above. 

Shared  variables  are  a  convenient  means  of  passing  data  between  different 
tasks  in  a  system.  Shared  variables,  associated  with  tasks,  are  established 
with  the  pragma  SHARED.  The  primary  advantage  of  using  shared  variables  is 
that  same  efficiency  in  data  transfer  within  the  program  is  typically 
introduced.  This  advantage  is  almost  always  offset  by  the  problems  caused 
by  using  shared  variabl.es.  Ensuring  the  security  of  data  "shared"  among 
tasks  is  particularly  difficult,  because  the  flew  of  program  control  is 
harder  to  trace  when  tasking  is  involved.  Therefore,  the  security  of  an  Ada 
TCB  system  is  complicated  when  it  incorporates  shared  variables.  When  a 
task  is  terminated  the  memory  containing  its  data  is  returned  to  the  heap 
without  being  scrubbed. 

Example:  This  example  illustrates  shared  variable  scope/visibility  deterrent 
in  a  package  specification.  That  is,  any  tar’  in  any  package  or 
subprogram  that  withs  package  Highly_Visible_  Package  can 
access  and  thus  modify  Shared_ACL_Variables  L  inner  that  is 
difficult  to  trace . 

with  Access_Control_List_Types_Package ; 
package  Highly_Visible_Tasks_Package  is 
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Shared_ACL_Variables  :  Access_Control_List_Types_Package. 

Named_Obj  ect_Record_Type ; 


—  pragma  SHARED  is  not  currently  supported  in  VAX  Ada. 
pragma  SHARED  (  Shared_ACL_Variables  ) ; 

—  Both  Resource_A_Task  and  Resouroe_B_Task  and  any  other  task  .in 

—  another  package  that  viths  package  Highly_Visible_Package  has 

—  access  to  Shared_ACL_Variables! 

task  Resouroe_A_Task  is 
entry  Get_f  rom_Resource_B ; 
entry  Send_to_Resource_B; 

end  Resource_A_Task ; 

task  Resource_B_Task  is 
entry  Get_fran_Resource_A; 
entry  Send_toJResource_A; 

end  Resource  B  Task; 


end  Highly_Visible_Tasks_Package  ; 


2. 2. 2. 6  Use  Clauses  and  Renaming  Declarations: 

Ada's  "use  clause  achieves  direct  visibility  of  declarations  that  appear  in 
the  visible  parts  of  named  packages."  Ada's  "renaming  declaration  declares 
another  name  for  an  entity."  The  use  of  the  use  clause  and  renaming  make 
identifying  the  origin  of  an  invoked  subprogram  difficult.  The  inpact  on 
testing  is  that  the  specification  and  definition  of  the  invoked  subprogram 
are  not  accessible  to  a  tester.  Also,  a  similar  effect,  which  is  equally 
adverse,  occurs  in  maintenance,  when  it  is  difficult  to  identify  the  origin 
of  the  invoked  subprogram. 

Examples:  These  examples  illustrate  the  obfuscation  introduced  by  the 
use  clause  and  renaming  declarations.  The  examples  of  the 
use  clause  and  renaming  declaration  follow  the  initial  declaration 
of  package  Generic_Access_Control_List_Manager_Package ,  which  is  a 
trusted  library  package . 

generic 
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type  Name_Type  is  private; 
type  ACLJRecord_Type  is  private? 


package  Generic__Access_Control_List_Manager_Package  is 


procedure  Get_ACL_Record 

(  Name  :  in  Name_Type; 

ACL  Record  :  out  ACL_Record_Type  ) ; 


end  Generic_Access_Control_List_Manager_Package; 


with  Access_Control_List_Types_Package ; 
with  Mardatory_Access_Control_Types_Package  ? 
with  Mardatory_Access_Control_Manager_Package; 
with  Audit_Trail_Manager_Package  ? 

package  body  Generic_Access_Control_List_Manager_Package  is 

—  The  user  car.  gain  only  indirect  access  to  instantiated 

—  access  control  list  through  the  subprograms  declared  in  the 

—  package  specification.  Thus  the  access  control  list  data 

—  structure  is  hidden  from  the  user  of  this  package.  The 

—  typical  list  manipulation  operations  (  e.g. ,  as  illustrated 

—  by  Boodh  1987A  and  Feldman  1985  )  are  only  provided  in  the 

—  package  body. 


—  Typical  list  manipulation  operations 


procedure  Get_ACL_Record 


( 

\ 


Mama 

ACL_Record 


Mama  rT\  rrvr>  • 

out  ACL_Record_’fype  )  is 
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begin  —  Get_ACL_Record 


—  Sequence  through  the  access  control  list  data  structure 

—  using  the  typical  list  manipulation  operations  to  locate 

—  and  get  the  indicated  access  control  list  record. 


end  Get  ACL  Record; 


end  Generic_AocessjCtontrol_List_Manager_Package; 


Example  1:  Obfuscation  introduced  by  the  use  clause 

with  BasicjrCB_Types_Package ; 

use  Basic_TCB_Types_Package; 

with  Access_Control_List_Types_Package; 

use  Aocess_Ctontrol_List_Types_Package; 

with  Mandatory_Access_Control_Types_Package  ; 

with  Generic_Access_Control_List_Manager_ Package; 

generic 


tope  Password_7Ype  is  private; 


package  Generic_User_Identification_and_Authentication_Package  ic 

—  Instantiation  of  Generic_Access_Control_List_Manager_Package 
package  Named_Ob j  ects_Access_Control_List_Manager_Package  is  new 

Generic_Access_Control_List_Manager_Package 
(  Namejiype  =>  N  ame_of_Ob j  ect_Type , 

ACL_Record_Type  =>  Naired_Ctoject_Record_Type  )  ; 

use  NamedjObjects_Access_Control_List_Manager_Package; 

—  Hie  locations  of  the  declarations  of  Name_of_ObjectJiype 

—  and  Named_Ob j  ect_Record_Type  are  new  lost  due  to  the 
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—  use  clauses,  use  Basic_TCB_Types_Package  and 

—  use  Access_Control_List_Types_Package,  respectively! 


*  •  • 

procedure  Check_Password 

(  Password  :  in  Passwordjiype; 

lxx^_MAC_Record ' :  in 
Mandatory Jtecessj2ontrol_Types_Package . 
MACJRecord_Type  ) ; 


end  Generic_User_Identification_and_Authentication_Package ; 


with  Audit_Trail_Manager_Package; 

package  body  Generic_User_Identification_and_Authentication_Package  is 


procedure  Check  Password 

(  Password  :  in  Password_Type ; 

Local_MAC_Record  :  in 
Mandatory_Access_Control_'iypes_Package . 
MAC_Record_Type  )  is 


Name  :  Name_of_Ob j  ect_Type ; 

ACL_Recond  :  NamedjDb j  ect_Record_Type ; 


begin  —  Check_Password 

—  Ihe  location  of  the  specification  of  Get_ACL_Record 

—  is  now  lost  due  to  the  use  clause, 

—  use  NairedjC&jects_Access_Ci)ntrol_List_Manager_Package! 

Get_ACL_Peoord  (  Name.  ACI^_Pecord  )  ? 
end  Check  Password; 
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end  Gener ic_U  ser_Ident  i  f  icat ion_and_Authent icat ion_Package  ; 


Example  2:  Obfuscation  introduced  by  renaming  declarations 

with  Bcisic_TCB_Types_Package ; 

with  Access_Control_List_'I’ypes_PacJjage ; 

with  Mandatory_Access_ControlJiypes_Package; 

with  Generic_Access_Control_List_Manager_Package; 

generic 


type  Password _iype  is  private; 


package  User_Identification_and_Authentication_Package  is 


procedure  Clieck_Password 

(  Password  :  in  Password_Type ; 

Local_KAC_Record  :  in 

Mandatory_Access_Control_Types_Package . 
MAC_Pecord_Type  ) ; 


end  User_Identification_and_Authentication_Package ; 


with  Audit_Trail_Manager_Package; 

package  body  User_Identification_and_Authentication_Package  is 

—  Instantiation  of  Generic_Access_Control_List_Manager_Package 
package  Named_Ob j  ects_Access_Control_List_Manager_Paokage  is  new 
Generic_Access_Control_List_Manager_Package 
(  Name_Type  =>  Basic_TCB_Types_Package . 

Name_of_Obj  ect_Type . 

ACL_Record_Type  =>  Access_Control_List_Types_Package . 

Narr>ed_0bj  ect_Record_Type  ) ; 
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procedure  Get_Access_Control_List_Reoord ; 

(  Name  :  in  Bas  icJICB_Types_Package . 

Name_of_Obj  ect_Type ; 

ACLJRecord  :  out  Access J3ontrol_ListJTypes_Padcage. 

Named_Ob j  ect_Record_Type  ) 

renames  NamedjOb j  ects_AccessjControl_List_Manager_Package . 
Get_ACL_Record  ? 


procedure  CheckJPasswond 

(  Password  :  in  Passwond_Type; 

Loccd_MAC_Record  :  in 
Mandatory_AccessjOontrol_T¥pesJPackage . 
MAC_Record_Type  j  is 


Name  :  F^icJICBJiypesJPackage .  Name_of_Ob j  ect_Tyte  ; 

ACL.  Record  :  Access_Control_lAst_Types_Package . 

NamedjOb  j  ect JRecord_Type , 


begin  —  Check_Password 

—  The  location  of  the  sper.  'float ion  of 
—  Get_Access_Control_List_Recoru, 

—  i.e.,  Named jCtojects_Access_Control_List_Manager  Package. 

—  Get_  ACLJRecord  is  now  lost  due  to  the  renaming  declaration! 

Get_Access_Control_List_ Record  (  Name,  ACL_Record  )  ; 

end  Check  Password; 


aid  UserJEdentif ication_and_Authentication_tackage ; 


2 . 7 . 2 . 7  Unchecked  Programming: 

Ada  provides  two  unchecked  programming  features,  unchecked  storage 
deallocation  and  unchecked  type  conversion.  "The  predefined  generic  library 
subprograms  TjNCHEO<ED_DEAIIDCAITC)N  and  U1^CHECKED_CC»WERSI0N  are  used  for 
unchecked  storage  deallocation  and  for  unchecked  type  conversions" 
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[ANSl//MILr-STD-1815A~19833 .  Some  Ada  canpilers,  such  as  the  DEC  VAX  Ada, 
allow  unchecked  conversion  with  private  and  Limited  private  types.  This 
allows  the  benefits  of  information  hiding  provided  by  theses  private  types 
to  be  circumvented  and  thus  allows  the  introduction  of  security  breaching 
devices,  such  as  covert  channels.  The  use  of  unchecked  storage  deallocation 
may  allow  an  unauthorized  user  or  subject  to  gain  access  to  the  storage. 
The  potential  problems  associated  with  its  use  are  similar  to  those 
associated  with  the  use  of  dynamic  storage.  Using  unchecked  type  conversion 
can  defeat  the  strong  typing  capabilities  of  Ada.  This  impedes  testing  the 
security  of  an  Ada  TCB. 

Example:  This  example  illustrates  the  deterrent  introduced  by  unchecked  type 
conversion  of  a  private  type,  in  particular,  in  VAX  Ada.  The 
violations  of  the  private  type,  KeyJType,  are  indicated  by  the 
inline  contents  in  the  procedure  Test_Key. 

package  Key_Manager_Package  is 
type  KeyJType  is  private; 

Null_Key  ;  constant  KeyJType; 
procedure  Get_Key  (  K  :  out  Keyjtype  ) ; 
function  "<"  (  X,  Y  :  KeyJType  J  return  BOOLEAN; 
function  "+"  (  X,  Y  :  KeyJType  )  return  KeyJType; 

private 

type  KeyJType  is  new  NATURAL; 

NullJKey  :  constant  KeyJType  :=  0; 
end  Key_Manager_ Package; 


package  body  Key_Manager_Package  is 


Last_Key  :  KeyJType  :=  0; 


procedure  Get_Key  (  K  :  out  KeyJType  )  is 
begin 

Last_Key  :=  Last_Key  +  1; 

K  :=  Last_Key; 
end  Get_Key; 


ti^ii  /  v  \r  •  vc 


»  rTV  \ 

begin 

return  NATURAL  (  X  )  <  NATURAL  (  Y  )  ? 
end  ; 


tVV\T  T7hKT 


function  "+"  (  X,  Y  :  Keyjiype  )  return  KeyJType  is 
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begin 

return  Key  Type  (  NATURAL  (  X  )  +  NATURAL  (  Y  )  ) ; 
end  M+M ; 

end  Key_Manager_Package ; 


with  Key_Manager_Package  ; 
with  UNCHECKEDjCDNVERSION; 
procedure  Test_Key  is 

function  Key_Content  is  new  UNCHECKED^ODNVERSION 
(  SOURCE  =>  Key  Manager  Package.  Key  Type, 

TAR  EH?  =>  INTEGER  ) ; 

function  Taitpered_with_Key  Content  is  new  UNCHECKED  CONVERSION 
(  SOURCE  =>  INTEGER, 

TARGET  =>  Key_Manager_Package.  KeyJType  ) ; 

Key_Value  :  Key Jlanager_Package .  KeyJType 

:=  KeyJtonager_Package7  NullJKey; 

Key_Integer  :  INTEGER  :=  7? 

Key_Relation  :  BOOLEAN  :=  FALSE; 

begin  —  Test_Key 

—  1.  Test  unchecked  conversions. 

—  l.a  The  following  statement  illustrates  unchecked  conversion 

—  of  an  object  of  INTEGER  type  and  its  assignment  to 

—  Key_Value,  which  .is  a  private  type! 

Key_Manager_Package.  Get_Key  (  Key_Value  ) ; 

Key_Integer  :=  Key_Conterrt  (  S  =>  Key_Value  ) ; 


—  l.b  The  following  statement  illustrates  unchecked  conversion 

of  an  abject  of  INTEGER  type  and  its  assignment  to 

—  Key_Value ,  which  is  a  private  type! 

KeyJEnteger  :=  13; 

KeyjValue  ;=  Taii^eredjwith_Key_Content  (  S  =>  Key_Integer  ) ; 
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2.  Test  express ior  compatibility  with  unchecked  conversions. 

2. a  Test  expression  conpatibility  of  an  object  of 

Key_Manager_Package . Key_Type  and  an  object  of  INTEGER 
type. 


Key_Integer  :=  10; 

Key_Manager_Package .  Get_Key  (  Key_Value  ) ; 

Key_Integer  :=  Key_Integer  +  KeyjContent  (  S  =>  Key_Value  ) ; 


—  2.b  Test  expression  compatibility  of  an  object  of  INTEGER 

type  and  an  object  of  Key_Manager_Package . Key_Type . 

Key_Manager_Package .  Get_Key  (  Key_Value  ) ; 

Key_Integer  :=  20; 

declare 

function  "+"  (  X,  Y  :  Key_Manager_Package.  Key_Type  )  return 
Key_Manager_Package .  KeyyType  renames 
Key_Manager_Package.  "+" ; 


begin 

Key_Value  :=  Key_Value  + 

Tarrpered_with__Key_Content  (  S  =>  Key_Integer  )  ; 

end;  —  block 


—  3.  Test  parameter  compatibility  with  unchecked  conversions. 

—  3. a  Test  parameter  compatibility  of  an  object  of  INTEGER 

—  type  to  an  object  of  Key_Manager_Package.KeyJiype. 

Key_Integer  ;=  30; 

Key_Marager_Package.  Gst_Key  (  Key_Value  ) ; 

Key_Integer  :=  Key_Integer  *  Key_Content  (  S  =>  Key_Value  )  ; 


3.b  Test  parameter  compatibility  of  an  object  of 

Key_Manager_Package . Key_Type  to  an  object  of  INTEGER 
—  type. 

Key_Relation  :=  FALSE; 
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Key_Manager_Pac};age.  Get_Key  (  Key_Value  ) ; 

Key_Integer  :=  40; 

Key_Relation  := 

Key_Marvager_Package .  "<"  (  Key_Value, 

Tairpered_with_Key_Conterrt  (  S  =>  Key_Integer  )  ) ; 
end  Test_Key; 


2. 2. 2. 8  Exceptions: 

The  major  difficulty  with  exceptions  [Tripathi]  in  the  Ada  language  from  the 
point  of  view  of  software  development  of  TCBs  is  the  dynamic  manner  in  which 
exceptions  are  propagated,  and  the  resulting  complexity  that  derives  from 
attempting  analysis  during  testing  of  programs.  This  complexity  is 
furthered  by  the  fact  that  exceptions  are  propagated  "as  is,"  which  could 
cause  an  unhandled  exception  to  propagate  from  several  levels  down  to  a 
routine  that  has  no  understanding  of  the  meaning  of  the  exception.  A  stack 
package  with  a  private  implementation  that  raises  INDEX_ERRQR  in  the 
environment  of  the  calling  procedure  would  be  totally  unexpected  and  either 
unhandled  or  mishandled. 

Through  adequate  containment  of  the  exceptions  -  conversion  of  unhandled 
exceptions  to  some  R0UTINE_ERR0R  on  exit  from  a  block  (within  a  package  or 
not) ,  or  explicit  use  of  others  clauses  at  all  possible  functions  (not  a 
convenient  approach)  -  the  complexity  could  be  reduced. 

Another  matter  of  concern  with  respect  to  exceptions  is  due  to  the  non¬ 
specificity  of  the  language  with  respect  to  modes  of  parameter  passing.  If 
a  compiler  passes  an  in  out  parameter  by  copy  on  entry  and  on  exit,  the 
actual  parameter  may  never  be  updated  if  the  routine  raises  an  exception, 
whereas  if  the  parameter  is  passed  by  reference,  changes  to  the  actual 
parameter  may  change  the  passed  formal  parameter,  and  the  value  will  have 
been  updated  in  the  presence  of  a  raised  exception. 

In  addition  using  pragma  SUPPRESS  prevents  the  raising  of  exceptions  for 
selected  checks,  which  can  serve  to  monitor  the  proper  execution  of  the 
program  during  runtime  Thus,  this  pragma  also  can  adversely  affect  the  TCB 
security.  It  should  also  be  noted  that  Ada  code  generated  when  using  pragma 
SUPPRESS  cannot  be  trusted  to  work  as  expected,  because  Ada  compilers 
currently  are  not  validated  when  pragma  SUPPRESS  is  used. 

Examples:  These  examples  illustrate  the  deterrent  introduced  by  transfer  of 
control  of  program  execution  by  exception  ha] riling.  In  the  first: 
example,  an  exception  raised  during  execution  of  a  deeply-nested 
subprogram  can  cause  control  flow  to  be  unpredictably  altered.  In 
the  second  example,  an  exception  is  raised  during  execution  of  a 
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task  which  is  handled  by  another  task,  thus,  control  flew  also  can 
be  unpredictably  altered. 

Exanple  l:  Deterrent  introduced  by  transfer  of  control  of  program  execution 
by  exception  handling  through  several  nested  subprograms 

package  Handle_Nestedj5ubprograms_Exceptions_Package  is 

procedure  HandleJSxceptions ? 

end  Handle_Nested_Sufcprograms_Except  ions_Package ; 

with  TEXT_IO; 

package  body  Handle_Nested_Subprograms_Exceptions_Package  is 
Password_is_lnvalid  :  exoqoticn; 
procedure  Check_Password  is 

Password_is_Incorrect  :  BOOLEAN  :=  FALSE; 
begin  —  Check_Password 
'  '  •  •  • 

if  Password_is_Incorrect  then 
raise  Password_is_Inval  id ; 
end  if; 

• 

end  Check_Password; 

procedure  Handle_Exceptions  is 
begin  —  Handle_Exceptions 

CheckJPassword ; 
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exception 


when  Password_is_Invalid  => 

TEXTJIO.  PUT  (  "The  password  is  invalid! "  ) ; 


when  others  => 

TEXT_IO.  H7T  (  ,fWe  have  a  problem  here!"  ) ; 
end  Handle_Exceptions ; 

end  Handle JfestedJSubprograirs JEXcept  ions_Package  ; 

Example  2:  Deterrent  introduced  by  transfer  of  control  of  program  execution 
by  exception  handling  across  tasks 

package  Handle_Exceptions_Across_Tas3cs_Package  is 

procedure  Check_Password  ; 

end  HcU^dle_Exceptions_Acros3_Tasks_Package ; 

with  TEXT_IO; 

package  body  Handle_Exceptions_Across_Tasks_Package  is 
Passw:-rd_is_Invalid  :  exception; 

task  Raise_Irrvalid_Password_Exception_Task  is 


entry  Check_Password_Val  idity ; 


end  Raise_Inval  id_Password_Except  ion_Task ; 
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task  Handle_Exoeptions_Task  is 
•  •  • 

entry  Handle_Invalid_Password; 

"  •  •  • 

i 

end  Handle_Exceptions_Task; 

procedure  CheckJPassword  is 
begin  —  Check_Password 

—  •  •  • 

Raise_Invalid_Password_Excqption_Task.  Check_Password_Validity ; 
'  •  •  • 

Handle_Exceptions_Task.  Handle_Invalid_Password; 

end  Check_Password ; 

task  body  Raise_Inval  id_Password_Except ion_Task  is 
Password_is_Incorrect  :  BOOLEAN  :=  FALSE; 
begin  —  Raise  _Invalid_Password_Exceptions_Task 
•  ♦  • 

accept  Check_  Password_Val  idity  do 

if  Password_is_Incorrect  then 
raise  Password  is  Invalid; 
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end  if; 


end  Check_Pcissword_Val  idity ; 

~  •  ♦  • 

end  Raise_InvalidJ?asswordJSxception_Task; 

task  body  Handle_Exceptions_Task  is 
begin  —  Handle_Exceptions_Task 
•  •  • 

accept  Handle_Invalid_Passwcrd; 

•  •  • 

exception 


whan  Password_is_Irrvalid  => 

TEXT_IO.  HJT_IZNE  (  "The  password  is  invalid!"  ) ; 


when  others  => 

TEXT_IO.  FUT_LINE  (  "We  have  a  problem  here!"  )  ? 
end  Handle_Exceptions_Task; 


end  Handle_Exceptions_Across_Tasks_Package ; 


2. 2 .2. 9  Interface  with  other  languages; 

Ada  provides  the  means  to  interface  with  other  languages  using  the  pragma 
INTERFACE.  Using  multiple  high -order  languages,  or  using  assembly  language 
with  a  high-order  language,  makes  a  system  more  difficult  to  understand. 
The  difficulty  here  is  not  with  the  pragma  INTERFACE  per  se,  but  rather  with 
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using  more  than  one  language  in  a  system.  Ada  code  has  more  potential  of 
being  self-documenting  than  other  high-order  languages  because  its  syntax  is 
logical  and  similar  to  English.  Also,  Ada  allows  the  use  of  a  sufficient 
number  of  characters  in  its  identifiers  to  make  them  more  readable  and 
understandable  than  the  identifiers  of  other  high-order  languages. 

The  difficulty  with  allowing  machine  code  insertions  in  developing  TCBs  is 
the  inability  to  correlate  the  specification  of  the  machine  code 
instructions  with  the  intended  abstract  behavior  at  the  Ada  language  level. 
If  it  is  possible  to  specify  the  intended  behavior,  it  would  likely  be 
preferable  to  program  in  Ada;  if  not,  attempting  to  use  such  insertions 
would  stymie  the  development  of  TCBs. 

Example  1:  This  example  illustrates  interfacing  Ada  with  the  programming 
language  C. 

pragma  INTERFACE  (  C,  rat  ) ;  —  obviously,  the  reference  monitor 


Example  2;  This  example  illustrates  interfacing  Ada  with  DEC  VAX-11 1  s  MACRO 
assembly  language. 

pragma  INTERFACE  (  MACRO,  TCB  ) ;  —  only  an  Ada  shell  is  required 


2.2.2.10  Representation  Clauses  and  Implementation-Dependent  Features: 

Ada  provides  means  to  directly  interact  with  the  underlying  hardware  and 
operating  system  using  its  representation  clauses  and  implementation- 
dependent  features.  As  with  interfacing  with  other  languages,  the 
beneficial  Ada  features  are  no  longer  available  in  these  parts  of  the 
system.  Using  representation  clauses  and  implementation-dependent  features 
may  allow  penetration  of  the  TCB  through  the  underlying  hardware  or 
operating  system,  which  clearly  could  allcw  compromising  the  security  of  an 
Ada  TCB  system. 

Example:  This  example  illustrates  the  deterrent  introduced  by  an  interrupt 
defined  by  an  address  clause.  Note  that  address  clauses  are  not 
currently  supported  in  VAX  Ada. 

procedure  Penetrate_Memory_Space  is 

Char  :  CHARACTER; 
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task  lnput_Penetrator_Task  is 
pragma  T  DRITY  (  4  ) ; 

—  must  have  at  least  the  priority  of  the  interrupt 

entry  Get_Charac±er_from_Peretrator_Input_Address 
(  Char  :  out  CHARACTER  )  ; 

entry  Save_Hardware_Buf  f er_Character ; 

—  assuming  that  SYSTEM.  ADCRESS  is  an  INTEGER  type 
for  Save_Hardware_Buf f er_Character  use  at  16#0020# ; 

aid  Input_Penetrator_Task  ; 


task  Output_Penetrator_Task  is 
pragma  HRIORITY  (  4  ) ; 

—  must  have  at  least  the  priority  of  the  interrupt 

entry  Depos  it_Character_into_Hardware_Buf  f  er ; 

entry  PutjCharacter_into_Penetrator_Output_Address 
(  Char  :  in  CHARACTER  ) ; 

—  assuming  that  SYSTEM.  ADDRESS  is  an  INTEGER  type 

for  Depos it_Charac±er_into_Hardware_Buf f er  use  at  16^0024  #; 

end  Output  JPenetrator_Task; 


task  body  lnput_Penetrator_Task  is 

Max_Size_of_Intemal_Input_Buffer  :  constant  POSITIVE 
:=  64; 

Intemal_Input_Buf  f  er  : 

array  (  1  . .  Max_Size_of_Internal_Input_Buffer  ) 
of  CHARACTER; 

Input_Buffer_Pointer  :  POSITIVE  :=  1; 
Output_BufferJ?o inter  ;  POSITIVE  :=  1; 

Buffer  Count  :  INTEGER  :=  1; 
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Hardware  j2iaracter_Buf f er  :  CHARACTER; 

for  Hardware_Character_Baf f er  use  at  16#0100#; 

begin  —  Input_Penetrator_Task 
loop 
select. 

when  Buffer_Count  >  0  => 

accept  Get_Character_f  rtm_Penetrator_Input_Address 
(  Char  :  cut  CHARACTER  )  do 

Char  :=  Internal_Input_Buffer  ( 

Output_Buffer_Pointer  ) ; 

end  Get_Character_f rom_Penetrator_input_Address ; 

Output  J3uffer_Pointer  := 

Output_Buf  f  er_Po  i  nter  mod 
Max_Sizejof_Internal__Ir^xit_Buffer  +  1? 

BufferjCount  :=  Buffer_Count  -  1? 

or 

when  Buffer_Count  < 

Max_Size_of_Intemal_Input_Buffer  => 

accept  Save_Hardware__Buffer_Character  do 

Internal_Input_Buffer  ( 

Input_Buffer_Pointer  )  := 
Hardware_Character_Buf f er ; 

end  Save_Hardware_Buf  f er_Character ; 

Input_Buffer_Fointer  := 

Input_Buffer_Po inter  mod 
Max_Size_of_Intemal_Input_Buffer  +  1; 

Buffer_Count  ;=  Buffer_Count  +  1; 

end  loop; 

end  Input_Penetrator_Task; 
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task  body  Output_Penetrator_Task  is 

Max_Si2e_of_Internal_Output_Buffer  :  constant  POSITIVE 

:=  64 ; 

Internal jXitput_Buf  f er  : 

array  (  1  ..  Max_S  i  ze_o  f _I  ntema  l_CXatput_Buf  f  er  ) 
of  CHARACTER; 

Input_Buffer_Po inter  :  POSITIVE  :=  1; 
Output_Buffer_Pointer  :  POSITIVE  :=  1; 

Buffer_Count  :  INTEGER  :=  1; 

Hardware_Character_Buffer  :  CHARACTER; 

for  Hardware_Character_Buffer  use  at  16#0200#; 

Harx3ware_Qiaracter_Buffer_is_Errpty  :  BOOLEAN  :=  TRUE; 

begin  —  Output_Penetrator_Task 
loop 
select 

accept  Depos  i t_Character_into_Harx3ware_Bu  f  f er ; 

if  Buffer_Count  >  0  then 

Hardware_Character_Buffer  := 
Intemal_Output_Buffer  ( 

Output_Buf  fer_Po inter  ) ; 

Output_Buffer_Pointer  := 
Output_Buffer_Pointer  mod 
Max_Size_of_Intemal_Output_Buffer  +  1; 

Baffer_Count  :=  Buffer_Count.  -  1; 

else 

Hardware_Character_Buffer_is_Enpty  :=  TRUE; 
end  if; 

or 

when  Buffer_Count  < 

Nax_Size_of_Intemal_Cutput_Buf  f  er  => 
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aooept 

Put_Charac±er_into_Penetrator_Output_Address 
(  Char  :  in  CHARACTER  )  do 

Interr^_Cutpat_Boffer  ( 

Inpat_Buf fer_Po inter  )  :=  Char; 

end  Put_Charac±er_into_Penetrator_Output_Address; 

Input_Buffer_Po  inter  := 

Input_Buffer_Po  inter  mod 
l^_Size_of_Internal_Output_Baffer  +  1; 

Buffer_Count  :=  Buffer_Caunt  +  1; 

if  Hardware_Character_Buffer_is_Enpty  then 

Hardware_Character_Buffer  := 
Internal_Cutput_Buffer  ( 
(XrtputJBuffer_Pointer  ) ; 

Output_Buf  f er_Pointer  := 

Output_Buffer_Pointer  mod 

Max_Size_of_Intemal_Output_Buffer  +  1; 

Buffer_Count  :=  Buffer_Count  -  1; 

Harx3ware_Character_Baffer_is_Eirpty  :=  TRUE; 
end  if; 
end  select; 
end  loop; 

end  Oatput_Penetrator_Task; 


begin  —  Penetrate Jfernory_Space 


Input_Penetrator_Task . 

Get_Character_frcm__Penetrator_Iiput_Address  f  Char  ) ; 


Oatput_Penetrator_Task . 

Put_Character_into_Penetrator_Output_Address  (  Char  ) ; 
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end  Penetrate JfemoryjSpaoe; 


2.2.2.11  System  timing  from  package  CALENDAR: 

Ada  provides  access  to  system  timing  through  the  package  CALENDAR.  If  the 
accuracy  of  the  system  timing  available  through  the  package  CALENDAR  is 
inadequate  for  the  needs  of  the  TCB,  then  its  security  may  be  ccnpramised 
(e.g. ,  if  the  TCB  has  to  run  under  recil-time  timing  constraints) .  That  is, 
the  system  timing  available  from  package  CALENDAR  may  not  correspond 
precisely  to  the  system  clock.  It  should  be  noted  that  only  system  timing 
is  available  from  package  CALENDAR,  which  would  be  required  for  time 
stamping.  To  get  timing  from  an  external  clock  a  new  package  must  be 
developed,  probably  with  representation  clauses,  which  introduces  their  own 
complications,  as  discussed  above.  The  potential  dangers  of  this 
relationship  between  system  timing  and  package  CALENDAR  should  be  the 
subject  of  future  research  with  Ada  runtime  environments. 


2.2.2.12  Tailoring  and  Configuring  Ada  Compiler  and  Runtime  System: 

Tailoring  of  an  Ada  compiler  or  runtime  system  is  the  actual  modification  of 
the  code  of  the  Ada  compilation  system  [Baker  1988]  at  which  time  validation 
of  the  Ada  compiler  may  be  ccnpramised  and  Trojan  horses  may  be  inserted. 
Configuration  of  an  Ada  compiler  or  runtime  system  is  the  reselection  of 
compiler  options  and  parameters  provided  by  the  Ada  compiler  vendor. 
Configuration  may  allow  a  compiler  or  runtime  system  to  nan  conveniently  on 
various  host  and  target  combinations.  Unsafe  selection  of  options  and 
parameters  may  open  paths  for  the  TCB  tc  be  penetrated.  Thus,  modifying  the 
Ada  compiler  or  runtime  system  of  a  TCB  by  tailoring  or  configuring  may 
compromise  the  security  of  the  TCB. 


2.3  Benefits  of  Using  Tools  to  Develop  Ada  Software  for  TCB  Systems 

The  following  infoonnation  on  tools  is  taken  liberally  from  Technology  Training 
Corporation's  seminar,  Developing  Ada  Systems,  presented  by  Mr.  Jerry  Mungle 
[Mungle  1988]. 
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2.3.1  Desirable  Features  of  Tools  for  the  Development  of  Ada  Software  for  TCB 
Systems 

The  following  features  of  software  development  tools  aid  the  development  of  Ada 
software  for  Ada  TCB  systems.  No  existing  tool  has  all  of  these  features.  A 
highly  desirable  software  development  tool  would  meet  the  following  requirements: 

Support  the  full  software  life  cycle  (including  the  special  needs 
of  real-time  software  development)  from  requirements  through  design, 
configuration  management,  and  maintenance; 

Support  various  development  methodologies,  such  as  Object  Oriented 
Development,  PAMELA  [Cherry  1984]  and  Structured  Analysis  Development; 

Support,  graphical  design  tools,  e.g.,  Booch  [1987A  and  1987B]  and  Buhr 
[1984]  Diagrams,  PAMELA,  Data  Flow  Diagrams,  Control  Flew  Diagrams,  and 
Structured  Analysis; 

Support  the  generation  of  Ada  Program  (or  Process)  Design  Language 
(PDL)  and  perhaps  Diana  Source  Representation; 

Support  the  generation  of  data  dictionaries,  process  specifications, 
and  DOD-STD-2 167A  documentation; 

Support  the  generation  of  error  reports; 

Have  an  Ada  language-sensitive  editor,  a  configurable  Ada  symbolic 
debugger,  and  a  configurable  Ada  pretty  printer; 

Support  the  tracing  of  the  satisfaction  of  security  requirements; 

Be  available  on  various  machines,  e.g.,  VAX,  SUN,  APOLLO,  IBM  AT,  and 
Macintosh. 


2.3.2  Tools  Available  for  the  Development  of  Ada  Software  for 
TCB  Systems 

The  following  tools  are  available  for  the  development  of  Ada  systene.  They  do 
not  inherently  insure  the  development  of  a  secure  system. 

A.  AdaGRAFH: 

It  supports  three  methodologies:  PAMELA,  Object  Oriented 

Development,  and  Structured  Analysis  Development. 
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It  provides  Ada-specific  support  (one-to-one  correspondence)  of 
graphical  design  elements  to  Ada. 

It  automatically  generates  Hierarchical  Process  Graphs  (HPG) , 
Software  Architecture  Data  Bases,  Ada  PDL  plus  task  idioms,  Module 
Maps,  and  Data  Dictionary. 

It  runs  on  PC  XT  and  AT  and  VAX/VMS. 

B.  AdaGEN: 

-  ..  It  supports  Object  Oriented  Development. 

It  provides  Ada-specific  support  by  drawing  Booch  diagrams, 
drawing  'Buhr  diagrams,  and  generating  compilable  Ada  PDL  from 
diagrams. 

It  runs  on  the  PC  and  SUN  ocnputer. 

C.  TEAMWDRVAda: 

It  supports  Ada  Structure  Graphs  (Buhr  graphs)  and  Structured 
Analysis  Development. 

It  automatically  generates  Ada  code  and  DOD-STD-2167A  documenta¬ 
tion. 

-  It  produces  data  flew  diagrams,  data  dictionaries,  process 
specifications,  control  flew  diagrams,  state  transition  diagrams, 
and  state  event  matrices,  decision  tables,  process  activation 
tables,  structure  charts,  and  entity  relationship  diagrams. 

It  interfaces  with  documentation  production  tools. 

It  provides  multiuser  support  on  Apollo,  DEC,  Hewlett  Packard, 
IBM,  and  SUN. 

D.  BYRON  PDL: 

It  supports  unlimited  user-definable  report  production. 

It  produces  Ada  PDL,  Diana  source  representation,  and  DOD-STD-2167 
documentation. 

It  provides  program  configuration  management. 

E.  AISLE  and  ADADL: 

It  is  a  family  of  tools  that  provides  project  management  support, 
especially  in  the  form  of  an  extremely  large  number  of  reports. 
These  reports  include  type  cross  references,  error  reports, 
complexity  reports,  and  structure  charts. 

It  produces  Ada  PDL  and  code,  DOD-STD-2167A  documents,  and  data 
dictionaries. 

It  provides  an  Ada  code  printer. 

It  does  not  extend  Ada. 


B-40 


APPENDIX  t 

Benefits  of  and  Potential  Deterrents  tc 
Us  me  Ada  rr,  Developing  Systems 


F.  DCDS: 

It  supports  the  Distributed  Computing  Design  System  methodology, 
and  it  supports  object  oriented  development  and  the  spiral  model 
of  software  development. 

It  specifically  supports  large,  ccrpl ex,  real-time,  distributed 
systems. 

It  supports  the  software  life  cycle  from  system  requirements 
through  integration  and  testing. 

Its  process  construction  system  supports  building  Ada  code  and  • 
automatically  generates  Ada  data  declarations. 

It  supports  software  configuration  management. 

It  produces  functional  networks,  requirements  networks,  Element- 
Relationship-Attribute  (ERA)  Specifications,  data  flew  diagrams, 
N2  charts,  and  Ada  PDtycode. 

It  automatically  generates  D0D-STD-2167A  documents. 

It  runs  on  the  VAX  and  SUN. 
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This  section  provides  a  mapping  of  Ada  constructs  that  would  be  appropriate  to 
the  implementation  of  the  TCB  structures  and  functions  defined  in  the  TCSEC.  The 
class  B3  criteria  are  used  as  the  template  of  the  generalized  TCB  criteria 
because  they  are  the  highest  level  Jt  security  criteria  under  consideration. 
Also,  the  Ada  constructs  mapped  to  these  criteria  can  similarly  be  mapped  to  the 
TCB  criteria  of  lower  security  classes.  The  four  TCB  criteria  subsections 
considered  are  Security  Policy,  Accountability,  Assurance,  and  Documentation. 
For  further  discussion  of  the  various,  topics,  refer  to  Appendix  A.  All  quotes 
are  taken  from  the  TCSEC. 


GENERALIZED  TCB  CRITERIA 

"The  class  B3  TCB  must  satisfy  the  reference  monitor  requirements  that  it  mediate 
all  accesses  of  objects,  be  tamperproof,  and  be  small  enough  to  be  subjected  to 
analysis  and  tests.  To  this  end,  the  TCB  is  structured  to  exclude  code  not 
essential  to  security  policy  enforcement,  with  significant  system  engineering 
during  TCB  design  and  implementation  directed  toward  miniuzing  its  complexity. 
A  security  administrator  is  supported,  audit  mechanisms  are  expanded  to  signal 
security-relevant  events,  and  system  recovery  procedures  are  required.  The 
system  is  highly  resistant  to  penetration." 


3.1  Security  Policy 

A  security  policy  describes  how  users  may  access  documents  or  other  information. 
It  is  the  set  of  laws,  roles,  and  practices  that  regulate  how  an  organization 
manages,  protects,  and  distributes  sensitive  information. 


3.1.1  Discretionary  Access  control 

Discretionary  access  control  provides  a  means  of  restricting  access  to  objects 
based  on  the  identity  of  subjects  and/or  groups  to  which  they  belong.  The 
controls  are  discretionary  in  the  sense  that  a  subject  with  a  certain  access 
permission  is  capable  of  passing  that  permission  (perhaps  indirectly)  to  any 
other  subject  (unless  restrained  by  mandatory  access  control) .  An  enforcement 
mechanism,  (e.g. ,  access  control  lists)  must  allcw  users  to  specify  and  control 
sharing  of  those  objects  and  must  provide  controls  to  limit,  propagation  of  access 
rights. 
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Application  of  Ada  Constructs  ana  Features: 

Enforcement  medianisms  that  consist  of  lists,  such  as  access  control  lists, 
can  be  created  with  linked  lists  and  queues,  using  either  static  or  dynamic 
storage  constructs  (e.g. ,  using  arrays  or  access  types,  respectively). 
Though  linked  lists  and  queues  are  more  typically  implemented  using  dynamic 
storage  constructs  created  with  Ada’s  access  types,  which  provide  more 
efficient  memory  usage,  linked  lists  and  queues  created  with  arrays  provide 
more  efficient  execution.  In  addition,  the  lists  can  be  represented  by 
abstract  data  types,  which  consist  of  Ada's  strong  data  typing  encapsulated 
in  packages.  For  further  explanation  of  these  constructs,  refer  to  Section 
2.0. 

Tasking  would  be  necessitated  if  concurrent  processes  are  to  be  used  in  more 
complex  TCB  systems  where  multiuser  and  multisubject  requirements  (e.g., 
simultaneously  monitoring  accesses  to  control  lists  by  multiple  subjects) 
are  present.  For  further  explanation  of  these  constructs,  refer  back  to 
Section  2.0. 

Nonvolatile  versions  of  major  lists,  e.g. ,  access  lists,  need  to  be  accessed 
from  disk  or  tape,  which  require  input  and  output  operations  whose  security 
is  protected  with  protocols  that  satisfy  the  class  of  the  given  TCB.  For 
further  explanation  of  these  features,  refer  to  Section  2.0. 


3.1.2  Object  Reuse 

Object  reuse  is  the  reassignment  to  seme  subject  of  a  medium  (e.g. ,  page  frame 
disk  sector,  magnetic  tape)  that  contained  one  or  more  objects.  To  be  securely 
reassigned,  such  media  must  contain  no  residual  data  from  the  previously 
contained  object (s) .  The  TCB  must  assure  that  when  a  storage  object  is  initially 
assigned,  allocated,  or  reallocated  to  a  subject  from  the  TCB's  pool  of  unused 
storage  objects,  the  object  contains  no  data  for  which  the  subject  is  not 
authorized. 

Application  of  Ada  Constructs  and  FeatU7.es: 

The  reuse  of  objects  involves  the  management  of  memory  used  for  storing 
objects.  This  may  involve  the  management  of  dynamic  storage  as  well  as 
static  storage  in  a  secure  manner.  Also,  objects  can  be  represented  by 
abstract  data  types,  which  are  implemented  with  Ada's  packages  and  user- 
defined  data  types.  Tasking  and  shared  variables  would  be  required  to 
manage  object  reuse  when  concurrent  processes  are  warranted  for  efficient 
multiuser  and  multisubject  TCB  system  operation.  For  further  explanation  of 
these  constructs,  refer  to  Section  2.0. 
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s.l.'J  Labels 

A  sensitivity  label  is  a  piece  of  information  that  represents  the  security  level 
of  an  object  and  that  describes  the  sensitivity  (i.e.,  classification)  of  the 
data  in  the  object.  Sensitivity  labels  are  used  by  the  TCB  as  the  basis  for 
mandatory  access  control  decisions.  They  are  associated  with  each  ADP  system 
resource  (e.g. ,  subject,  storage  object)  that  is  directly  or  indirectly 
accessible  by  subjects  external  to  the  TCB,  and  they  must  be  maintained  by  the 
TCB.  To  import  non-labeled  data,  the  TCB  must  request  and  receive  from  an 
authorized  user  the  security  level  of  the  data,  and  all  such  actions  must  be 
auditable  by  the  TCB.  Also,  the  TCB  must  enforce  subject  sensitivity  labels  and 
device  labels. 

Application  of  Ada  Constructs  and  Features: 

Sensitivity  labels  can  be  treated  as  objects,  which  can  be  represented  by 
abstract  data  types.  These  consist  of  Ada's  strong  data  typing  encapsulated 
in  packages.  The  exportation  of  labeled  information  typically  involves 
input  and  output  using  secure  protocols,  which  can  also  be  represented  by 
abstract  data  types.  Tasking  and  shared  variables  would  be  required  to 
manage  subject  sensitivity  labels  and  their  exportation  when  concurrent 
processes  are  warranted  for  efficient  multiuser  and  multisubject  TCB  system 
operation.  For  further  explanation  of  these  constructs,  refer  to  Section 
2.0. 


3.1.4  Mandatory  Access  Control 

A  mandatory  access  control  is  a  means  of  restricting  access  to  objects  based  on 
the  sensitivity  (as  represented  by  a  label)  of  the  information  contained  in  the 
objects  and  the  formal  authorization  (i.e. ,  clearance)  of  subjects  to  access 
information  of  such  sensitivity.  It  prevents  "same  types  of  Trojan  horse  attacks 
by  imposing  access  restrictions  that  cannot  be  bypassed,  even  indirectly.  Under 
mandatory  controls,  the  system  assigns  both  subjects  and  objects  special 
attributes  that  cannot  be  changed  on  request  as  can  discretionary  access  control 
attributes  such  as  access  control  lists.  The  system  decides  whether  a  subject 
can  access  an  object  by  comparing  their  security  attributes."  [Gasser  1988,  p.61] 
Thus,  a  TCB  must  enforce  a  mandatory  access  control  policy  over  all  resources 
(i.e.,  subjects,  storage  objects  and  I/O  devices)  that  are  directly  or  indirectly 
accessible  by  subjects  external  to  the  TCB.  All  subjects  and  storage  objects 
must  be  assigned  sensitivity  labels  that  are  a  combination  of  hierarchical 
classification  levels  and  non-hierarchical  categories,  and  the  labels  must  be  the 
basis  of  the  mandatory  access  control  decisions.  Also,  a  TCB  must  be  able  to 
support  two  or  more  security  levels. 
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Application  of  Ada  Constructs  and  Features: 

The  management  of  a  mandatory  access  control  policy  is  performed  typically 
with  an  implementation  of  the  Bell  and  LaPadula  security  model  that 
regulates  the  security  of  accessing  objects  by  subjects  and  the  assignment 
of  sensitivity  labels  to  enforce  the  policy.  This  requires  classifications 
of  the  objects  that  are  to  be  protected  by  this  policy.  This  may  involve  the 
management  of  dynamic  and  static  storage  in  a  secure  manner.  Also,  objects 
can  be  represented  by  abstract  data  types,  which  are  implemented  with  Ada's 
packages  and  user-defined  data  types.  Similarly,  the  policy  could  be 
represented  by  a  package.  Tasking  and  shared  variables  would  be  required  to 
manage  mandatory  access  controls  when  concurrent  processes  are  warranted  for 
efficient  multiuser  and  multisubject  TUB  system  operation.  For  further 
explanation  of  these  constructs,  refer  to  Section  2.0. 


3 . 2  Accountability 

Accountability  is  the  monitoring  of  access  to  and  operation  of  a  TCB  system  by 
using  identification  and  authentication  of  users  requesting  access  to  the  system, 
maintenance  of  trusted  communication  paths,  and  auditing  of  accesses  to  the  TCB. 


3.2.1  Identification  and  Authentication 

Identification  consists  of  using  unique  identifiers  that  are  associated  with  each 
user  (such  as  a  last  name,  initials,  or  account  number),  that  everyone  knows, 
that  no  one  can  forge  or  change,  and  that  all  access  requests  can  be  checked 
against.  The  identifier  is  the  means  by  which  the  system  distinguishes  users. 
In  particular,  a  TCB  must  require  users  to  identify  themselves  to  it  before 
beginning  to  perform  any  other  actions  that  the  TCB  is  expected  to  mediate. 

Authentication  consists  of  associating  a  real  user  (or  more  accurately,  a  program 
running  on  behalf  of  a  user)  with  a  unique  identifier,  namely,  the  user  ID.  "The 
system  must  separate  authentication  information  (passwords)  from  identification 
information  (unique  IDs)  to  the  maximum  extent  possible  because  passwords  are 
secret  and  user  IDs  are  public"  [Gasser  1988,  p.23] .  A  TCB  must  maintain 
authentication  data  that  includes  information  for  verifying  the  identity  of 
individual  users  as  well  as  information  for  determining  the  clearance  and 
authorizations  of  individual  users.  It  uses  this  data  to  authenticate  the  user's 
identity  and  to  determine  the  security  level  and  authorizations  of  subjects  that 
are  created  to  act  on  behalf  of  the  individual  user.  The  TCB  must  protect 
authentication  data  so  that  it  cannot  be  accessed  by  an  unauthorized  user.  It 
must  be  able  to  enforce  individual  accountability  by  providing  the  capability  to 
uniquely  identify  each  individual  ADP  system  user.  Also,  it  must  provide  the 
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capardity  of  associating  the  individual  identity  with  ail  a ad^ table  action 
taken  by  that  individual. 

Application  of  Ada  Constructs  and  Features: 

The  management  of  identification  and  authentication  data  involves  using 
corresponding  abstract  data  types,  which  consist  of  Ada's  strong  data  typing 
encapsulated  in  packages.  This  management  may  also  include  using  dynamic 
storage  as  well  as  static  storage  in  a  secure  manner.  Similarly,  the 
identification  and  -authentication  processes  may  be  represented  by  packages. 
Tasking  and  shared  variables  may  be  required  to  manage  security  data  when 
concurrent  processes  are  warranted  for  efficient  multiuser  and  multisubject 
TCB  system  operation.  For  further  explanation  of  these  constructs,  refer  to 
Section  2.0. 


3.2.2  Trusted  Path 

A  trusted  path  is  a  mechanism  by  which  a  person  at  a  terminal  can  communicate 
directly  with  the  TCB.  This  mechanism  can  only  be  activated  by  the  person  or  the 
TCB  and  cannot  be  imitated  by  unevaluated  software.  A  TCB  must  support  a  trusted 
communication  path  between  itself  and  users  for  use  when  a  positive  TCB-to-user 
connection  is  required  (e.g. ,  login,  change  subject  security  level) . 
Communication  via  this  trusted  path  must  be  activated  exclusively  by  a  user  or 
the  TCB  and  must  be  logically  isolated  and  unmistakably  distinguishable  from 
other  paths.  The  Trusted  Path  for  a  Class  B3  TCB  needs  to  allow  bi-directional 
access,  from  user  to  TCB  and  from  TCB  to  user. 

Application  of  Ada  Constructs  and  Features: 

Trusted  paths  require  secure  input  and  output  communication  paths  between 
the  user  or  subject  and  the  TCB.  Trusted  paths  can  be  treated  as  objects, 
which  can  be  represented  by  abstract  data  types.  These  consist  of  Ada's 
strong  data  typing  encapsulated  in  packages.  Tasking  and  shared  variables 
may  be  required  to  manage  trusted  paths  whan  concurrent  processes  are 
warranted  for  efficient  multiuser  and  multisubject  TCB  system  operation. 
For  further  explanation  of  these  constructs  and  features,  refer  to  Section 
2.0. 


3.2,3  Audit 

An  audit  of  accesses  to  and  operation  of  TCB  operation  is  maintained  in  a  set  of 
records  (i.e. ,  an  audit  trail)  that  collectively  provide  documentary  evidence  of 
processing  used  to  aid  in  tracing  from  original  transactions  forward  to  related 
records  and  reports,  and/or  backward  from  records  and  reports  to  their  component 
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source  transactions .  The  TCE  must  be  able  to  create,  maintain,  and  protect  from 
modification  or  unauthorized  access  or  destruction  an  audit  trail  of  accesses  to 
the  objects  it  protects.  Audit  data  must  be  protected  by  the  TCB  so  that  read 
access  to  it  is  limited  to  those  who  are  authorized  for  audit  data.  A  TCB  must 
be  able  to  record  use  of  identification  and  authentication  mechanisms, 
introduction  of  objects  into  a  user's  address  space,  deletion  of  objects,  actions 
taken  by  computer  operators  and  system  administrators  and/or  system  security 
officers,  and  other  security  relevant  events.  A  TCB  must  be  able  to  audit  any 
override  of  human-readable  output  markings.  For  each  recorded  event,  the  audit 
record  must  identify  the  date  and  time  of  event,  user,  type  of  event,  and  success 
or  failure  of  the  event.  For  identification  and  authentication  events,  the  audit 
record  must  include  origin  of  request  (terminal  ID) .  For  events  that  introduce 
an  object  into  a  user's  address  space  and  for  object  deletion  events,  the  audit 
record  must  include  the  name  of  the  object  and  the  object's  security  level.  The 
ADP  system  administrator  must  be  able  to  selectively  audit  the  actions  of  any  one 
or  more  users  based  on  individual  identity  and/or  object  security  level.  A  TCB 
must  be  able  to  audit  the  identified  events  that  may  be  used  in  the  exploitation 
of  covert  storage  channels.  A  TCB  must  contain  a  mechanism  that  is  able  to 
monitor  the  occurrence  or  accumulation  of  security  auditable  events  that  may 
indicate  an  imminent  violation  of  security  policy;  this  mechanism  must  be  able  to 
immediately  notify  the  security  administrator  when  thresholds  are  exceeded.  If 
the  occurrence  or  accumulation  of  these  security  relevant  events  continues,  the 
system  must  take  the  least  disruptive  action  to  terminate  the  event. 

Application  of  Ada  Constructs  and  Features: 

Managing  audit  data  requires  maintaining  an  audit  trail.  An  audit  trail  is 
typically  recorded  on  disk  and/or  tape,  which  requires  secure  input  and 
output  communication  paths  within  a  TCB  that  includes  a  secure  disk  and/or 
tape.  The  audit  data  and  audit  trail  can  be  treated  as  objects,  which  can 
be  represented  by  abstract  data  types.  These  consist  of  Ada's  strong  data 
typing  encapsulated  in  packages.  Also,  the  audit  data  may  be  (at  least 
partially)  located  in  dynamic  storage.  Tasking  and  shared  variables  may  be 
required  to  manage  the  audit  data  and  audit  trail  when  concurrent  processes 
are  warranted  for  efficient  multiuser  and  multisubject  TCB  system  operation. 
For  further  explanation  of  these  constructs  and  features,  refer  to  Section 
2.0. 


3.3  Assurance 

Assurance  of  the  correctness  of  a  TCB  system's  security  controls,  as  specified 
by  the  security  requirements,  determines  the  extent  that  the  security 
architecture  must  dictate  many  details  of  the  development  process.  The  two  types 
of  assurance  that  must  be  considered  are  operational  and  life-cycle. 
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3.3.1  Operational  Assurance 

Operational  assurance  includes  the  following  aspects:  system  architecture,  system 
integrity,  covert  channel  analysis,  trusted  facility  management,  and  trusted 
recovery. 


3. 3. 1.1  System  Architecture 

The  TUB  must  maintain  a  domain  for  its  own  execution  that  protects  it  from 
external  interference  or  tampering.  It  must  maintain  process  isolation  through 
the  provision  of  distinct  address  spaces  under  its  control.  The  TCB  must  be 
internally  structured  into  well-defined  largely  independent  modules.  It  must 
make  effective  use  of  available  hardware  to  separate  those  elements  that  are 
protection-critical  from  those  that  are  not.  TCB  modules  must  be  designed  such 
that  the  principle  of  least  privilege  is  enforced.  Features  in  hardware,  such  as 
segmentation,  must  be  used  to  support  logically  distinct  storage  objects  with 
separate  attributes  (namely,  readable  and  writable) .  The  TCB  user  interface  must 
be  completely  defined  and  all  elements  of  the  TCB  must  be  identified.  The  TCB 
must  be  designed  and  structured  to  use  a  complete,  conceptually  simple  protection 
mechanism  with  precisely  defined  semantics ;  this  mechanism  must  play  a  central 
role  in  enforcing  the  internal  structuring  of  the  TCB  and  the  system.  The  TCB 
must  incorporate  significant  use  of  layering,  abstraction,  and  data  hiding. 
Significant  system  engineering  must  be  directed  toward  minimizing  the  complexity 
of  the  TCB  and  excluding  from  the  TCB  modules  that  are  not  protection-critical. 

Application  of  Ada  Constructs  and  Features: 

The  TCB's  system  architecture  must  be  modular,  and  use  data  abstraction  with 
information  hiding  in  its  implementation.  Ada  is  well  suited  to  incorporate 
modularity  with  its  packages  and  subprograms  and  to  implement  data 
abstraction  and  information  hiding  with  abstract  data  types.  To  ensure 
system  integrity  and  to  prevent  the  creation  of  covert  channels,  the 
creation  of  TCB  system  features  (dynamic  storage,  input  and  output 
communications  within  the  TCB  and  between  the  user  or  subject  and  the  TCB, 
tasking  and/or  global  and  shared  variables)  must  address  the  potential 
security  problems  associated  with  their  implementation  and  use.  For  further 
explanation  of  these  constructs  and  features,  refer  to  Section  2.0. 


3. 3. 1.2  System  Integrity 

Hardware  and/or  software  features  must  be  provided  tliat  can  be  used  to 
periodically  validate  the  correct  operation  of  the  on-site  hardware  and  firmware 
elements  of  the  TCB. 
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Application  of  Ada  Constructs  and  Features: 

Ada  allows  for  the  crv  *ion  of  more  readable  code  which  helps  the  validation 
process. 


3. 3. 1.3  Covert  Channel  Analysis 

The  search  for  covert  channels  required  in  this  analysis  is  facilitated  by  having 
the  TCB's  software  and  documentation.be  readable  and  understandable. 

Application  of  Ada  Constructs  and  Features: 

Ada  allows  for  the  creation  of  more  readable  code,  which  helps  the 
identification  of  covert  channels. 


3.3. 1.4  Trusted  Facility  Management 

The  majority  of  issues  related  to  trusted  facility  management  are  not  software 
issues.  Rather,  they  are  concerned  with  the  responsibilities  of  the  security 
administrator  and  the  ADP  system  administrative  personnel. 

Application  of  Ada  Constructs  and  Features: 

Ada  allows  for  the  creation  of  more  readable  code,  which  helps  the 
management  of  a  trusted  facility. 


3.3. 1.5  Trusted  Recovery 

Procedures  and/or  mechanisms  must  be  provided  to  assure  that,  after  an  ADP  system 
failure  or  other  discontinuity,  recovery  without  a  protection  compromise  is 
obtained. 

Application  of  Ada  Constructs  and  Features: 

When  implemented  with  proper  security  considerations,  Ada's  exception 
handling  mechanism  can  be  used  to  help  implement  trusted  recovery.  For 
further  explanation  of  these  constructs,  refer  to  Section  2.0. 


3.3.2  Life-Cycle  Assurance 

Life-Cycle  assurance  includes  the  following  aspects:  security  testing,  design 
specification  and  verification,  and  configuration  management. 
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3.3.2. l  Security  Testing 

Security  mechanisms  of  the  ADP  system  must  be  tested  and  found  to  work  as  claimed 
in  the  system  documentation .  A  team  of  individuals  who  thoroughly  understand  the 
specific  implementation  of  the  TCB  must  subject  its  design  documentation,  source 
code,  and  object  code  to  thorough  analysis  and  testing.  The  team's  objective 
should  be  to  uncover  all  design  and  implementation  flaws  -  that  would  permit  a 
subject  external  to  the  TCB  to  read,  change,  or  delete  data  normally  denied  under 
the  mandatory  or  discretionary  security  policy.  This  will  assure  that  no  subject 
is  able  to  cause  the  TCB  to  enter  a  state  such  that  it  is  unable  to  respond  to 
communications  initiated  by  other  users.  The  TCB  must  be  found  resistant  to 
penetration.  All  discovered  flaws  must  be  corrected,  and  the  TCB  must  be 
retested  to  demonstrate  that  the  flaws  have  been  eliminated  and  that  new  flaws 
have  not  been  introduced.  Testing  must  demonstrate  that  the  TCB  implementation 
is  consistent  with  the  descriptive  top-level  specification.  No  design  flaws  and 
no  more  than  a  few  correctable  implementation  flaws  may  be  found  during  testing 
and  there  must  be  reasonable  confidence  that  few  remain. 

Application  of  Ada  Constructs  and  Features: 

Security  testing  of  the  TCB  system  is  promoted  by  having  the  system 
architecture  exhibit  modularity  and  using  data  abstractio^with  information 
hiding  in  its  implementation.  Ada  is  well  suited  to  incorporate  modularity 
with  its  packages  and  subprograms  and  to  implement  data  abstraction  and 
information  hiding  with  abstract  data  types.  Security  testing  of  the  TCB 
system  must  include  the  testing  of  all  implementations  of  the  following 
system  features:  dynamic  storage  management,  input  and  output  communications 
within  the  TCB  and  between  the  user  or  subject  and  the  TCB,  tasking  and/or 
global  and  shared  variables.  For  further  explanation  of  these  constructs 
and  features,  refer  to  Section  2.0. 


3. 3. 2. 2  Design  Specification  and  Verification 

A  formal  model  of  the  security  policy  supported  by  the  TCB  must  be  maintained  and 
be  proven  to  be  consistent  with  its  axioms.  A  descriptive  top-level  specifica¬ 
tion  (DTIS)  of  the  TCB  must  be  maintained  that  completely  and  accurately 
describes  the  TCB  in  terms  of  exceptions,  error  messages,  and  effects.  It  must 
be  shown  to  be  an  accurate  description  of  the  TCB  interface.  A  convincing 
argument  must  be  given  that  the  DUS  is  consistent  with  the  model. 
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3. 3. 2. 3  Configuration  Management 

A  configuration  management  system  must  be  in  place  that  maintains  control  of 
changes  to  the  descriptive  top-level  specification,  other  design  data, 
implementation  documentation,  source  code,  the  running  version  of  the  object 
code,  and  test  fixtures  and  documentation.  The  configuration  management  system 
must  assure  a  consistent  mapping  among  all  documentation  and  code  associated  with 
the  current  version  of  the  TCB.  Tools  must  be  provided  for  generation  of  a  new 
version  of  the  TCB  from  source  code  and  for  cotparing  a  newly  generated  version 
with  the  previous  ..TCB  .version  in.  order  to  ascertain  that  only  the.  intended 
changes  have  been  made  in  the  code  that  will  actually  be  used  as  the  new  version 
of  the  TCB. 


3.4  Documentation 

Documentation  is  an  important  part  of  the  software  development  process.  It  aids 
users  who  are  not  familiar  with  the  system  in  learning  how  to  use  the  system 
correctly.  It  aids  support  programmers  in  testing  the  system  to  ensure  that  a 
modification  has  not  had  a  negative  impact  on  the  system.  This  is  especially 
important  when  developing  a  TCB,  because  the  security  of  the  system  is  of  the 
utmost  importance.  While  this  is  true,  no  special  consideration  needs  to  be 
given  to  the  development  of  the  documentation  for  a  TCB.  The  documentation  must 
be  developed  to  meet  all  requirements  set  forth  in  the  TCSEC  and  must  be  complete 
and  up  to  date. 

Application  of  Ada  Constructs  and  Features: 

The  documentation,  particularly  the  design  documentation,  must  clearly 
convey  the  implementation  of  the  TCB  system  architecture,  which  must  exhibit 
modularity,  and  use  data  abstraction  with  information  hiding  in  its 
implementation.  Ada  is  well  suited  to  incorporate  modularity  with  its 
packages  and  subprograms  and  to  implement  data  abstraction  and  information 
hiding  with  abstract  data  types.  These  features  not  only  aid  the 
understandability  of  the  code,  but  also  of  the  design  documentation.  The 
documentation  must  clearly  shew  hew  the  security  risks  are  handled, 
including  those  posed  by  the  following  TCB  system  features:  dynamic  storage 
management,  input  and  output  communications  within  the  TCB  and  between  the 
user  or  subject  and  the  TCB,  tasking  and/or  global  and  shared  variables,  and 
any  tailoring  or  configuring  of  the  Ada  compiler  or  runtime  system.  This 
discussion  of  the  application  of  Ada  constructs  to  documentation  i  plies  to 
the  following  four  subsections:  Security  Features  User's  Guide,  Trusted 
Facility  Manual,  Test  Documentation,  and  Design  Documentation.  For  further 
explanation  of  these  constructs  and  features,  refer  to  Section  2.0. 
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Ada's  self-documenting  capabilities  can  contribute  to  the  design  and  testing 
documentation.  The  self -documenting  capabilities  can  be  realized  better 
with  the  use  of  readable  and  understandable  mnemonics.  The  code  should 
exhibit  consistent  indentation.  Blank  lines  should  be  used  to  logically 
partition  the  code.  Garments  should  be  inserted  into  the  code  to  provide 
information  that  is  not  conveyed  by  the  code.  Each  package  and  subprogram 
should  have  a  header  that  states  its  purpose,  its  authors,  and  the  history 
(dates)  of  its  creation  and  revision (s) . 


3.4.1  Security  Features  User's  Guide 

A  single  summary,  chapter,  or  manual  in  user  documentation  must  describe  the 
protection  mechanisms  provided  by  the  TCB,  guidelines  on  their  use,  and  hew  they 
interact  with  one  another. 

Application  of  Ada  Constructs  and  Features: 

Ada  will  have  no  impact  on  the  development  of  the  Security  Features  User's 
Guide. 


3.4.2  Trusted  Facility  Manual 

A  manual  addressed  to  the  ADP  system  administrator  must  present  cautions  about 
functions  and  privileges  that  should  be  controlled  when  running  a  secure 
facility.  It  must  describe  the  o:>=rator  and  administrator  functions  'related  to 
security,  to  include  changing  the  yicurity  characteristics  of  a  user.  The  manual 
must  provide  guidelines  on  the  consistent  and  effective  use  of  the  protection 
features  of  the  system,  hew  they  interact,  how  to  securely  generate  a  new  TCB, 
and  facility  procedures,  warnings,  and  privileges  that  need  to  be  controlled  in 
order  to  operate  the  facility  in  a  secure  manner.  TCB  modules  that  contain  the 
reference  validation  mechanism  must  be  identified.  Procedures  for  secure 
generation  of  a  new  TCB  from  source  after  modification  of  any  modules  in  the  TCB 
must  be  described.  The  manual  must  include  the  procedures  to  ensure  that  the 
system  is  initially  started  in  a  secure  manner.  Procedures  must  also  be  included 
to  resume  secure  system  operation  after  ary  lapse  in  system  operation. 

Application  of  Ada  Constructs  and  Features: 

Ada  will  have  no  impact  on  the  development  of  the  Trusted  Facility  Manual. 
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3.4.3  Test  Documentation 

Hie  system  developer  must  provide  to  the  evaluators  a  document  that  describes  the 
test  plan,  test  procedures  that  shew  her.-;  the  security  mechanisms  were  tested,  and 
results  of  the  security  mechanisms'  functional  testing.  Documentation  must 
include  results  of  testing  the  effectiveness  of  the  methods  used  to  reduce  covert 
channel  bandwidths. 

Application  of  Ada  Constructs  and  Features: 

Ada  coding  should  be  self- documenting ,  as  discussed  in  Section  3.4,  so  that 
it  can  contribute  to  the  testing  documentation. 


3.4.4  Design  Documentation 

Documentation  must  be  available  that  provides  a  description  of  the  manufacturer's 
philosophy  of  protection  and  an  explanation  of  how  this  philosophy  is  translated 
into  the  TCB.  Hie  interfaces  between  the  TCB  modules  must  be  described.  A 
formal  description  of  the  security  policy  model  enforced  by  ths  TCB  must  be 
available  and  proven  that  is  sufficient  to  enforce  the  security  policy.  Specific 
TCB  protection  mechanisms  must  be  identified,  and  an  explanation  must  be  given  to 
shew  that  they  satisfy  the  model.  Hie  TCB  implementation  (i.e. ,  in  hardware, 
firmware,  and  software)  must  be  shewn,  using  informal  techniques,  to  be 
consistent  with  the  DTLS.  Hie  elements  of  the  DELS  must  be  shown,  using  informal 
techniques,  to  correspond  to  the  elements  of  the  TCB.  Documentation  must 
describe  how  the  TCB  implements  the  reference  monitor  concept  and  give  an 
explanation  why  it  is  tamper  resistant,  cannot  be  bypassed,  and  is  correctly 
implemented.  Documentation  must  describe  how  the  TCB  is  structured  to  facilitate 
testing  and  to  enforce  least  privilege.  Documentation  must  also  present  the 
results  of  covert  channel  analysis  and  the  tradeoffs  involved  in  restricting  the 
channels.  All  auditable  events  that  may  be  used  in  the  exploitation  of  known 
covert  storage  channels  must  be  identified.  The  bandwidths  of  known  covert 
storage  channels,  the  use  of  which  is  not  detectable  by  the  auditing  mechanisms, 
must  be  provided. 

Application  of  Ada  Constructs  and  Features: 

Ada  coding  should  be  self-documenting,  as  discussed  in  Section  3.4,  so  that 
it  can  contribute  to  the  design  documentation.  The  use  of  Ada  PDL  will 
assist  in  generating  readable  and  understandable  design  documentation. 


B-53 


APPENDIX  E 

Summarv  arc  Conclusions 


4.0  SUMMARY  AND  CONCLUSIONS 

4.1  Summary 

This  appendix  identified  benefits  and  potential  deterrents  of  using  Ada  in  the 
software  development  of  TCBs.  These  benefits  included  Ada's  assets  in  the 
application  of  sound  software  engineering  principles,  such  as  data  abstraction, 
information  hiding,  modularity,  and  localization.  Also  included  among  the 
benefits  were  such  Ada  constructs  as  strong  data  typing,  packages,  subprograms, 
and  tasks.  This  appendix  also  identified  and  categorized  potential  deterrents  of 
using  Ada  in  the  software  development  of  TCBs.  These  included  shortcomings 
inherent  to  programming  languages  in  general,  shortcomings  unique  to  the  Ada 
language,  and  benefits  of  using  tools  to  develop  Ada  software. 

Sections  2.0  and  3.0  addressed  the  issues  in  two  ways.  First,  Section  2.0 
focused  on  the  following  issues:  (1)  Benefits  of  Using  Ada  in  Developing  TCB 
Systems,  (2)  Potential  Deterrents  to  Using  Ada  in  Developing  TCB  systems,  (3) 
Shortcomings  inherent  to  programming  languages  in  general  in  developing  TCB 
systems,  (4)  Shortcomings  unique  to  the  Ada  language  in  developing  TCB  systems, 
(5)  Benefits  of  using  tools  for  developing  Ada  software  for  TCB  systems.  Section 
3 . 0  presented  these  issues  in  the  context  of  a  mapping  of  Ada  usage  to 
generalized  TCB  criteria.  Ada  constructs  were  identified  that  may  be  used  to 
implement  TCB  features  and  functions. 


4.2  Conclusions 

Because  Ada  was  designed  with  features  and  constructs  that  promote  recognized 
sound  software  engineering  principles,  more  so  than  other  current  HOLs,  it  is 
well  suited  as  the  implementation  language  of  TCBs.  Although  Ada  offers  various 
specific  benefits,  the  potential  deterrents  of  using  Ada  must  be  recognized  and 
addressed.  Though  these  potential  problems  were  identified  with  using  various 
Ada  features,  this  is  not  meant  to  imply  that  any  of  the  features  should  not  be 
used.  Rather,  the  security  of  the  TCB  must  not  be  compromised,  as  discussed  in 
Section  2.0,  when  any  of  the  constructs  and  features  are  used  in  the 
implementation  of  the  TCB. 
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1.0  INTRODUCTION 

This  appendix  presents  guidelines  for  developing  trusted  computing  bases  (TCBs) 
in  Ada.  It  is  meant  to  ccnplement  existing  standards.  The  user  of  this  appendix 
should  also  use  standards  or  guidelines  for  the  development  of  TCBs.  General  TCB 
development  issues  are  discussed  in  this  document  only  to  the  extent  that  they 
are  affected  by  Ada.  Also  the  developer  of  a  TCB  in  Ada  should  use  general 
purpose  Ada  guidelines  for  direction  on  the  general  use  of  Ada  features.  These 
guidelines  detail  the  use  of  Ada  features  only  as  they  would  be  used  for  specific 
aspects  of  TCB  development.  This  document,  therefore,  is  to  ccnplement  existing 
TCB  development  guidelines  and  general-purpose  Ada  coding  guidelines. 

1.1  Background 

This  appendix  provides  guidelines  on  how  to  use  Ada  in  the  development  of  TCB 
systems.  This  guidance  focuses  on  how  to  exploit  the  advantages  of  using  Ada, 
such  as  data  abstraction,  information  hiding,  modularity,  localization,  strong 
data  typing,  packages,  subprograms,  and  tasks. 

This  appendix  does  not  imply  that  software  alone  is  sufficient  for  ensuring 
security  in  a  TCB.  As  discussed  in  the  papers  "Secure  Ccnputing:  The  Secure  Ada 
Target  Approach, "  "iDCKing  Computers  Securely,"  and  "IDCK/ix:  On  Implementing 
Unix  on  the  LOCK  TCB,"  the  security  of  a  system  cannot  be  insured  with  software 
alone.  Hardware  is  fundamentally  important  to  TCB  system  security.  This 
appendix  does  not  discuss  hardware  aspects  of  TCB  systems.  If  the  reader  wishes 
to  investigate  the  hardware  issues,  he  should  consult  the  references  cited  above. 

1.2  Format 

This  appendix  consists  of  four  sections.  The  first  section  is  an  introduction 
which  consists  of  background  information  and  definitions  of  key  terms  that  appear 
in  this  document.  The  key  terms  section  includes  terms  found  in  the  glossary  of 
the  TCSEC,  the  Reference  Manual  for  the  Ada  PEoqramrrim  Language  (LRM)  [ANSI/MIL- 
STD-1815A-1983] ,  and  the  IEEE  Standard  Glossary  of  Software  Engineering 
Terminology  [IEEE  1983].  Sections  2.0  and  3.0  address  the  guidelines  in  two 
ways.  First,  Section  2.0  provides  definitions  of  and  general  programming 
guidelines  on  the  use  of  Ada  constructs  and  features  that  have  significant 
bearing  on  the  development  of  TCB  Systems.  These  guidelines  are  mapped  to  the 
LRM.  Several  Ada  constructs  are  virtually  or  literally  identical  to  those  of 
other  high  order  languages  such  as  FORTRAN  and  C.  In  these  instances,  the  phrase 
"No  Ada-specific  impact  on  TCBs"  appears  in  the  text.  Also,  some  subsection 
topics  are  addressed  bv  the  main  section  under  which  they  fall.  When  the 
subsection  adds  no  additional  effect  beyond  what  is  discussed  in  the  main  section 
the  phrase  "No  additional  Ada-specific  impact  on  TCBs"  appears.  Section  3.0 
provides  guidelines  on  the  application  of  Ada  constructs  and  features  in  the 
context  of  a  mapping  of  Ada  usage  to  generalized  TCB  criteria.  In  particular, 
class  B3  as  defined  in  the  TCSEC  is  used  as  a  template  for  the  generalized  TCB 
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criteria.  Though  potential  problems  exist  when  using  various  Ada  constructs  and 
features,  this  does  not  mean  that  any  of  the  constructs  and  features  should  not 
be  used.  Rather,  certain  sets  of  features  when  used  together  luost  be  used  in 
accordance  with  the  established  guidelines  to  ensure  the  security  of  the  TCB. 
Section  4.0  consists  of  a  summary  of  this  appendix  and  its  conclusions. 

1.3  Key  terms 

Several  key  words  appear  throughout  the  text  of  this  document.  These  words  have 
specific  meanings  within  the  context  of  certified  systems  and  their  definitions 
are  presented  here. 

The  following  definitions  are  taken  directly  from  the  TCSEC: 

Access  -  A  specific  type  of  interaction  between  a  subject  and  an  object  that 
results  in  the  flew  of  information  from  one  to  the  other. 

Audit  Trail  -  A  set  of  records  that  collectively  provide  documentary  evidence  of 
processing  used  to  aid  in  tracing  from  original  transactions  forward  to 
related  records  and  reports,  and/or  backwards  from  records  and  reports  to 
their  component  source  transactions. 

Covert  Charnel  -  A  communication  channel  that  allows  a  process  to  transfer 
information  in  a  manner  that  violates  the  system's  security  policy. 

Data  -  Information  with  a  specific  physical  representation . 

Discretionary  Access  Control  -  A  means  of  restricting  access  to  objects  based  on 
the  identity  of  subjects  and/or  groups  to  which  they  belong.  The  controls 
are  discretionary  in  the  sense  that  a  subject  with  a  certain  access 
permission  is  capable  of  passing  that  permission  (perhaps  indirectly)  on  to 
any  other  subject  (unless  restrained  by  mandatory  access  control) . 

Mandatory  Access  Control  -  A  means  of  restricting  access  to  objects  based  on  the 
sensitivity  (as  represented  by  a  label)  of  the  information  contained  in  the 
objects  and  the  formal  authorization  (i.e.,  clearance)  of  subjects  to  access 
information  of  such  sensitivity. 

Object  -  A  passive  entity  that  contains  or  receives  information.  Access  to  an 
object  potentially  implies  access  to  the  information  it  contains.  Examples 
of  objects  are:  records,  blocks,  pages,  segments,  files,  directories, 
directory  trees,  and  programs,  as  well  as  bits,  bytes,  words,  fields, 
processors,  video  displays,  keyboards,  clocks,  printers,  network  nodes,  etc. 


Sensitivity  Label  -  A  piece  of  information  that  represents  the  security  level  of 
an  object  and  that  describes  the  sensitivity  (e.g. ,  classification)  of  the 


APPENDIX  C 
Introduction 


data  in  the  object.  Sensitivity  labels  are  used  by  the  TCB  as  the  basis  for 
mandatory  access  control  decisions. 

Subject  -  An  active  entity,  generally  in  the  form  of  a  person,  process,  or  device 
that  causes  information  to  flew  among  objects  or  changes  the  system  state. 
Technically,  a  process/dcrain  pair. 

Trusted  Computing  Base  (TCB)  -  The  totality  of  protection  mechanisms  within  a 
computer  system  —  including  hardware  firmware,  and  software  —  the 
combination  of  which  is  responsible  for  enforcing  a  security  policy.  A  TCB 
consists  of  one  or  more  components  that  together  enforce  a  unified  security 
policy  over  a  product  or  system.  The  ability  of  a  TCB  to  correctly  enforce 
a  security  policy  depends  solely  on  the  mechanisms  within  the  TCB  and  on  the 
correct  input  by  system  administrative  personnel  of  parameters  (e.g. ,  a 
user's  clearance)  related  to  the  security  policy. 


Additional  Terms 

These  terms  are  included  because  they  appear  frequently  in  the  following  text. 

Pragma  -  A  compiler  directive.  That  is,  it  "is  used  to  convey  information  to 
the  compiler."  According  to  the  Reference  Manual  for  the  Ada 
Programming  Language  (LRM)  [ANSI/MIL-STD-1815A-1983] ,  the  predefined 
pragmas  (Refer  to  Annex  B  in  this  manual  for  descriptions)  "must  be 
supported  by  every  implementation .  In  addition,  an  implementation  may 
provide  implementation-defined  pragmas,  which  must  then  be  described  in 
Appendix  F,"  i.e.,  the  appendix  on  implementation-dependent 

characteristics  that  the  Ada  compiler  vendor  must  provide  in  his  Ada 
language  reference  manual. 

Security  -  The  protection  of  computer  hardware  and  software  from  accidental  or 
malicious  access,  use,  modification,  destruction,  or  disclosure.  [IEEE 
1983]  Security  also  pertains  to  personnel,  data,  communications,  and 
the  physical  protection  of  computer  installations.  Specifically,  for 
the  purposes  of  this  report,  security  is  defined  by  the  criteria  in 
the  TCSEC,  i.e.,  a  given  security  problem  corresponds  with  a  specific 
TCSEC  criteria. 
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2.0  MAPPING  OF  TCB  RELEVANT  ADA  CONSTRUCTS  AND  FEATURES  TO 
THE  REFERENCE  MANUAL  FOR  THE  ADA  PROGRAMMING  LANGUAGE 


This  section  provides  software  engineering  and  programming  guidelines  for  using 
Ada  constructs  and  features  in  developing  TCB  systems.  These  guidelines  are 
mapped  to  the  IRM  [ANSI/MHH3TD-1815A-1983]  to  provide  a  convenient  means  of 
reference.  These  guidelines  are  for  software  engineering  practices  and 

programming  conventions  for  using  the  Ada  language  to  develop  TCB  systems. 
Although  these  guidelines,  are  recommendations,  justification  .should  be  made  for 
any  deviation  from  them.  The  development  of  any  high  quality  system,  and 
especially  that  of  a  TCB  system,  requires  strict  adherence  to  sound  software 
engineering  principles  and  practices,  from  requirements  analysis  and  design 
thrombi  coding  and  maintenance. 

Ada  supports  sound  software  engineering  principles,  including  the  following 
(Discussions  on  them  are  located  in  the  indicated  sections.) : 

Strong  Data  Typing  (3.  Declarations  and  Types) 

Data  Abstraction  (7.  Packages) 

Information  Hiding  (7.  Packages) 

Modularity  and  localization  (7.  Packages) 

Reusable  Code  (10.4  The  Program  Library) 

Note,  a  discussion  on  tailoring  and  configuring  Ada  compiler  and  runtime  systems 
is  located  in  Section  2.1. 

Although  this  appendix  does  not  advocate  abstaining  from  using  any  Ada 
constructs,  it  should  be  noted  that  each  of  them,  to  varying  degrees,  contributes 
to  a  large  Ada  runtime  library.  Eric  Anderson,  in  his  paper  "Ada's  Suitability 
for  Trusted  Computer  Systems,"  proposes  the  extreme  view  of  minimizing  the  Ada 
runtime  library  for  the  security  kernel  as  a  primary  goal  because  its  size  may 
lend  itself  to  hiding  covert  channels  and  Trojan  horses.  To  minimize  the  size  cf 
the  Ada  runtime  library,  he  proposes  the  following  severe  restrictions  in 
creating  the  security  kernel:  not  allowing  use  of  any  dynamic  storage,  tasking, 
exception  handling,  any  Ada  standard  packages  other  than  STANDARD  and  SYSTEM; 
limiting  the  use  of  runtime  constraint  checking,  math  and  conversion  routines, 
and  representation  clauses.  Addressing  security  issues  associated  with  the  Ada 
runtime  library  are  beyond  the  scope  of  this  document.  Clearly,  though,  Ada 
runtime  library  security  issues  need  to  be  addressed  by  further  research. 


Guideline: 

1.  Coding  guidelines  identified  in  the  remainder  of  Section  2.0  should  be  used 
in  conjunction  with  general  software  engineering  standards  and  with  Ada 
coding  standards.  The  guidelines  presented  here  address  only  the  use  of  Ada 
for  specific  TCB  criteria. 
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All  but  one  of  the  remaining  subsections  of  this  appendix  are  structured  in 
accordance  with  the  chapters  of  the  LEM.  The  remaining  subsection  covers 
tailoring  and  configuring  Ada  compilers  and  runtime  systems.  Each  subsection 
includes  descriptions  of  an  Ada  construct  or  feature,  programming  guidelines  for 
using  it  in  developing  TCB  systems,  and  examples  as  needed. 

More  general  coding  standard  issues,  such  as  limiting  the  amount  of  nesting  of 
loop  and  if  blocks  and  always  providing  an  others  clause  in  case  statements,  are 
not  addressed  by  the  guidelines  presented  here. 
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2-1.  Introduction 

This  chapter  of  the  DBM  introduces  the  Ada  language  standard.  The  two 
sections  of  primary  interest  to  developing  TCBs  are  Scope  of  the  Standard 
(Section  2  -  1.1),  which  discusses  Ada  standardization  and  portability,  and 
Classification  of  Errors  (Section  2  -  1.6). 


2  -  1.1  Scape  of  the  Standard 

This  definition  of  the  Ada  programming  language  was  developed  to  promote 
Ada's  standardization  and  portability.  Because  Ada,  more  so  than  other 
languages,  is  very  standardized  (in  particular  by  the  Department  of  Defense 
(DoD) )  no  subsets  or  supersets  of  Ada  are  allowed.  This  standardization  is 
assured  by  the  DoD's  process  of  validation  of  Ada  compilers.  This  aids  the 
portability  of  Ada  software  among  different  types  of  computers.  In 
particular,  an  Ada  TCB  system  is  likely  to  be  easier  to  port  between 
different  types  of  computers  than  if  the  TCB  were  developed  in  another 
language. 

Guidelines; 

1.  To  take  advantage  of  Ada's  standardization  and  portability  the  use  of 
the  following  items  should  be  avoided:  representation  clauses, 
implementation-dependent  features,  and  interfacing  with  other 
languages. 

2.  Issues  involving  such  features,  which  may  compromise  standardized  code 
and/or  code  portability,  should  be  addressed  as  early  as  possible  in 
the  development  of  a  TCB  system,  preferably  in  the  TCB's  requirements 
specification. 

3 .  The  implementation  of  these  features  should  be  monitored  during 
preliminary  and  detailed  design  reviews  and  code  walkthroughs. 


2  -  1.1.1  Extent  of  the  Standard 

No  additional  Ada-specific  impact  on  TCBs 


2  -  1.1.2  Conformity  of  an  Inplanentaticn  with  the  Standard 
No  additional  Ada-specific  inpact  on  TCBs 
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2  -  1.2  Structure  of  the  Standard 
No  Ada-specific  inpact  on  TCBs 


2  -  1.3  Design  Goals  and  Sources 

No  Ada-specific  impact  on  TCBs 


2  -  1.4  Language  Summary 

No  Ada-specific  impact  on  TCBs 


2  -  1.5  Method  of  Description  and  syntax  Notion 
No  Ada-specific  impact  on  TCBs 


2-1.6  Classification  of  Errors 

The  LRM  defines  four  types  of  errors:  compilation  time  errors,  runtime 
errors,  erroneous  execution,  and  incorrect  order  dependencies.  The  first  of 
these  four  types  of  errors,  compilation  time  errors,  are  commonly  referred 
to  as  syntax  errors,  and  will  not  allow  for  compilation  of  the  program.  The 
second  type  of  error,  the  runtime  error,  occurs  during  the  attempted 
execution  of  the  program,  and  is  canmonly  referred  to  as  an  "exception." 
Runtime  errors  in  general  have  been  widely  discussed  in  the  literature 
[Goodenough  and  Liskov  1985],  and  have  even  been  discussed  with  respect  to 
Ada  [Duckham  1980].  In  addition  to  this,  because  Chapter  7,  "Exceptions," 
is  devoted  entirely  to  this  topic,  its  discussion  will  be  deferred  to  that 
chapter.  The  remaining  error  types,  erroneous  execution  and  incorrect  order 
dependencies,  are  not  required  to  be  detected  at  compilation  or  execution, 
but  do  result  in  violations  of  certain  rules  of  the  Ada  language. 

Guidelines: 

1.  The  software  developer,  rather  than  the  Ada  language,  is  responsible 
for  the  detection  of  the  four  types  of  errors:  compilation  time 
errors,  runtime  errors,  erroneous  execution,  and  incorrect  order 
dependencies. 

2.  The  detection  of  these  four  types  of  errors  should  be  monitored  during 
preliminary  and  detailed  design  reviews  and  code  walkthroughs, 
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2-2.  Lexical  Elanents 

This  chapter  of  the  IRM  defines  the  lexical  elements  allowed  in  the  text  of 
an  Ada  compilation  unit.  It  also  describes  pragmas,  which  provide  certain 
information  for  the  compiler.  The  majority  of  these  items  have  little 
relevance  to  the  software  development  of  TCBs. 


2  -  2.1  Character  Set 

No  Ada-specific  impact  on  TCBs 


2  -  2.2  Lexical  Elements,  Separators,  and  Delimiters 
No  Ada-specific  inpact  on  TCBs 


2  -  2.3  Identifiers 

An  important,  key  to  the  readability  of  software  is  the  use  of  mnemonic 
identifiers.  Readability  of  software  is  a  key  component  of  software 
understandability . 


Guidelines: 

1.  Name  identifiers  with  clearly  readable  and  understandable  mnemonics. 

2.  Tailor  the  naming  of  identifiers  to  the  application  to  improve  the 
readability  of  programs  and  reduce  the  chance  for  errors  [ASOS  1987] . 


Examples:  The  following  examples  illustrate  clearly  readable  and 

understandable  mnemonic  identifier  names.  They  are  identifiers 
that  are  used  in  later  examples  in  this  appendix.  The  use  of  each 
identifier  should  be  clear  based  on  its  name.  This  set  of 
identifiers  is  taken  out  of  context;  therefore,  it  does  not 
constitute  compilable  code. 


Named_Object_A'  r_Record  —  see  2 
Max_Named_String_Length  —  see  2 
Named_Individuals_List_Type  —  see  2 
Scrubbed_Named^Ob  j  pcts_Li  st  —  see  2 


3.2.1 

3.2.2 
3.2.1 
3.2.1 
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2-2.4  Numeric  Literals 


Guideline: 

1.  Use  underscore  in  numeric  literals  to  add  clarity  cind  thus  reduce  the 
number  of  accidental  errors  [ASQS  1987]. 

Examples:  This  example  illustrates  underscoring  in  numeric  literals  which 
improve  the  readability  of  literals  that  have  many  digits. 
Underscores  are  used  in  place  of  ccnras  in  large  numbers.  In 
strings  of  digits  to  the  right  of  the  decimal,  an  underscore  is 
used,  for  exanple,  after  every  fifth  digit. 

123_456  rather  than  123456  —  integer  literal 

3.14159  26  rather  than  3.1415926  —  real  literal 


2  -  2.4.1  Decimal  Literals 

No  Ada-specific  impact  on  TCBs 


2  -  2.4.2  Based  Literals 
Guideline: 

1.  Use  base  literals  to  allow  clear  expression  of  bit  masks  and  other 
items  not  easily  expressed  in  decimal  notation  [ASOS  1987], 

Examples:  This  example  illustrates  base  literals. 

—  integer  literals  of  value  255 
2#1111JL111#  16#FF#  016#CFF # 


2  -  2.5  Character  Literals 

No  Ada-specific  impact  on  TCBs 


2  -  2.6  String  Literals 

No  Ada-specific  impact  on  TCBs 


C-13 


'K 


APFECIX  C 

Mapping  Of  TCB  Relevant  Ada  Constructs  and  Features  To 
The  Reference  Manual  For  The  Ada  Proorammino  Language 


1  -  2.7  Cements 

Comments  should  provide  additional  instructive  information  about  modules  and 
their  underlying  algorithms  that  is  not  conveyed  by  their  code. 

Guideline: 

1.  The  information  provided  in  comments  should  reflect  the  TCB's  design, 
and  promote  the  TCB's  coding  and  maintenance. 


2  -  2.8  Pragmas 

The  PRAOiA  construct  is  relevant,  although  this  chapter  of  the  LEM  does  not 
discuss  its  use  and  application,  but  only  rules  for  its  placement  within  the 
program  text.  For  the  discussion  of  its  use  and  application  see  Section  2- 
11.7. 


2  -  2.9  Reserved  Words 

No  Ada-specific  inpact  on  TCBs 


2  -  2.10  Allowable  Replacement  of  Characters 
No  Ada-specific  impact  on  TCBs 
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2-3.  Declarations  and  Types 

This  chapter  of  the  ISM  defines  the  type  mechanism,  the  means  for  declaring 
objects  of  the  types,  and  the  set  of  operations  on  the  types.  The  major 
areas  that  are  of  concern  to  the  development  of  TCBs  are  object  and  type 
declarations,  array  types,  and  access  types.  Static  storage  is  discussed  in 
Array  Types  (Section  2  -  3.6) .  Dynamic  storage  is  discussed  in  Access  Types 
(Section  2  -  3.8) . 

Ada's  strong  data  typing  facilities  provide  a  means  of  associating  related 
data  objects  with  data  types,  which  is  a  fundamental  aspect  of  data 
abstraction.  Strong  data  typing  serves  to  isolate  data  types.  For  a 
further  discussion  of  data  abstraction  refer  to  Section  2-7,  Packages. 


Guidelines: 

1.  Use  Ada's  strong  data  typing  to  create  user-defined  types,  namely, 
subtypes  and  derived  types. 

2.  Name  data  types  and  objects  with  clearly  readable  and  understandable 
mnemonics  that  promote  the  maintenance  of  the  code. 


2  -  3.1  Declarations 

No  Ada-specific  impact  on  TCBs 


2-3.2  Objects  and  Named  Numbers 
2  -  3.2.1  Object  Declarations 

An  erroneous  program  may  occur  if  it  includes  the  use  of  an  object  prior  to 
assigning  a  value  to  the  object.  The  formal  definition  of  the  language 
requires  that  the  default  value  for  objects  be  specified  when  declared. 


Guideline: 

1.  Initialize  data  items  in  their  declarations  [ASOS  1987]. 

2.  Disallow  references  to  objects  before  their  initialization.  This 
should  be  addressed  with  explicit  initialization  and  monitored  during 
code  walkthroughs.  That  is,  ensure  that  no  undefined  variable  will  be 
referenced  by  assigning  a  default  value  in  each  object  declaration. 

3.  Name  all  constants  and  literals  [ASOS  1987]. 
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Examples:  The  following  examples  illustrate  clearly  readable  and 

understandable  mnemonic  object  declarations.  This  set  of  object 
declarations  includes  the  initialization  of  the  objects. 

FtoJNamed_String_Length,  Name_String_Type ,  and  Blank_Name_String 
are  declared  in  package  BasicJTCB_Types_Package .  Because  only  essential 
features  of  this  package  need  to  be  shewn,  it  is  not  included  formally  in 
this  appendix. 

Blank_Name_String  :  Name_String_Type  —  see  2  -  3.6.3 

:=(!..  Max_Named_String_Length  =>'•);  —  see  2  -  3.2.2 


The  next  three  declarations  in  this  section  are  located  in  the  array 
types  version  of  package  Access_Control_List_Types_Package .  Because  only 
essential  features  of  this  package  need  to  be  shown,  it  is  not  included 
formally  in  this  appendix. 

Scrubbed_Nai«Ed_Cfc> j  ects_List  : 

Named_Ob  j  ects_List_Type  —  see  2-3.6 

Named_Ob j ects_List_Type ' 

(  others  =>  Basic_TCBJTypes_Package . 

Blank_Name_String  )  ; 

ScrubbedJNait^_Individuals_List  : 

Named_Individuals_List_Type  —  see  2-3.6 

:=  Named_Individuals_List_T?ype ' 

(  others  =>  Basic JTCBJTypes_Package. 

Blank_Name__String  ) ; 

Scrubbed_Groups_of_Named_Individ’uals_List  : 

GroupsjcfJNamed_Individuals_IustJiype  —  see  2-3.6 

:=  Groups_of_Named_Individuals_List_Type' 

(  others  =>  Basic_TCB_Types_Package. 

Blank_Name_String  ) ; 


The  next  three  declarations  in  this  section  are  located  in  the  access 
types  version  of  package  Access_Control_List_Types_Package.  Because  only 
essential  features  of  rhis  package  need  to  be  shewn,  it  is  not  included 
formally  in  this  appendix. 
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Scrubbed_Named_Ob j  ects_List  : 

Named _C&jec±s_List_Type  —  see  2-3.8 

:=  Named_Ob j  ects_List_Type ' 

(  Name  =>  BasicJTCB_Types_Package. 

Blank_Name_String , 

Next  =>  null  )  ; 

Scrubbed_Named_IndividualsJList  : 

Namea_Individuals_List_iype  —  see  2-3.8 

:=  Named_Individiials__Ldst_T^)e 1 

(  Name  =>  Bas  ic_TCB_Types_Package . 

Blank_Name_String , 

Next  =>  null  ) ; 

Scrubbed_Groi5)s_of_Named_Individuals_List  : 

Groups_of_Named_Individuals_JJist_Type  —  see  2-3.8 

:=  Groupsjcf JfemedJEndividualsJListJType ' 

(  Name  =>  Basic_TCB_Types_Package . 

Blank_Name_String , 

Next  =>  null  ) ; 


The  remaining  declarations  in  this  section  are  located 
in  both  the  access  and  array  types  versions  of 

package  Access_Control_List_Types_Package .  Because  only  essential 
features  of  this  package  need  to  be  shown,  it  is  not  included  formally  in 
this  appendix. 

Scrubbea_Named_Ob j  ect_ACL_Record  : 

Named_Ob j  ect_Record_riype  —  see  2-3.7 

:=  Naited_Object_Record_Type' 

(  Name  =>  Basic_TCB_Types_Package. 

Blank_Name_String , 

Sensitivity_Label  => 

Mandatory_Access_Control_Types_Package . 

Scrubbed_Sensitivity_Label ,  —  see  3  -  3.1.3 

Authorized_Naroed_Individuals_List  => 
Scrt±bed_Named_Individuals_List , 

Authorized_Groups_of_Named_Individuals_List  => 
Scruli^_Groups_of_Named_Iridividuals_List , 

Unauthori  zed_Naxned_Individual  s_List  => 
Scrubbed_Named_Individuals_List  )  ; 
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NamedjDb j  ect_ACL_Record  :  Named_Ob j  ect_Record_TVpe  —  see  2-3.7 
:=  Scrubbed_Named_Ob j  ect_ACL_Record ; 

Scrubbed J^aii^_Individual^CL_Record  : 

Named_IndividualJlecord_Type  —  see  2-3.7 

:=  Named_Individual_Record_Type ' 

(  Name  =>  Basic_TCB_Types_Package . 

Blank_Name_String , 

—  see  2  -  3.6.3 

Sensitivity  JLabel  => 

Mandatory_Access_ControlJiypes_Package . 

Scrubbed_Sensitivity'_Iabel ,  —  see  3  -  3.1.3 

NamedjObj  ects_List  =>  Scrubbed_Named_Ob j  ects_List  )  ; 


Named_Individual_ACX!_Record  : 

Named_Individual_Record_Type  —  see  2-3.7 

:=  Scrubbed_Named_Individual_ACL_Record ; 


ScrubbedjS:roup_of_Naiied_Individuals_ACL_Recond  : 

Group_of_Named_Individual s_Record_Type  —  see  2-3.7 

: =  Group_of_Named_Indiv: dual s_Record_Type ' 

(  Name  =>  Basic_TCB_Types_Package . 

Blank_Name_String , 

—  see  2  -  3.6.3 

Sensitivity_Label  => 
Mandatory_Access_Control_Types_Package . 

Scrubbed_Sensitivity_Iabel,  —  see  3  -  3.1.3 

Named_Ctojects_List  =>  Scrubbed_Named_Ob j  ects_List  ) ; 


Graup_of_Named_Individuals_ACL_Record  : 

Group_of_Nared_Ii'»dividuals_Record_Type  —  see  2-3.7 

:=  Scrui±)ed_Grcup_ofJ^amed_Individuals_ACL_Record? 


2  -  3.2.2  Number  Declarations 

The  use  of  number  declarations  improve  the  readability,  understandability, 
and  maintenance  of  code. 
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Guideline: 

1.  Use  mnemonic  number  declarations  to  make  code  more  readable  and 
understandable. 

Example:  The  following  example  illustrates  a  clearly  readable  and 
understandable  mnemonic  number  declaration 

Max_Named_String_Iength  is  declared  in  package  BasicJFCSJiypes__Package . 
Because  only  essential  features  of  this  package  need  to  be  shown,  it  is 
not  included  formally  in  this  appendix. 

Max_Named_String_Iength  :  constant  :=  80; 


2  -  3.3  Types  and  Subtypes 

Although  types  and  subtypes  within  Ada  are  well  behaved  with  respect  to 
developing  TCBs.  Memory  management  of  objects  of  array  types  and  access 
types  warrants  special  consideration. 


2  -  3.3.1  Type  Declarations 

Example:  The  following  example  illustrates  a  clearly  readable  and 
understandable  mnemonic  type  declaration. 

—  Dayjiype  is  declared  in  package  Bas  i  c_Types_Package .  Because  only 

essential  features  of  this  package  need  to  be  shown,  it  is  not  included 
formally  in  this  appendix. 

type  Day_Type  is  (  Sunday,  Monday,  Tuesday,  Wednesday, 

Thursday,  Friday,  Saturday  )  ; 

For  additional  discussion  refer  to  Section  2-3.  and  2  -  3.3. 


2  -  3.3.2  Subtype  Declarations 

Example:  The  following  example  illustrates  a  clearly  readable  and 
understandable  mnemonic  subtype  declaration. 

—  Weekday_Type  is  declared  in  package  Basic_  Types_Package .  Because  only 
essential  features  of  this  package  need  to  be  shewn,  it  is  not  included 
formally  in  this  appendix. 
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subtype  weekday _Iype  is  Day_lype  range  Monday  . .  Fnaay ; 

For  additional  discussion  refer  to  Section  2-3.  and  2  -  3.3. 


2  -  3.3.3  Classification  of  Operations 

No  additional  Ada-specific  impact  on  TCBs 


2  -  3.4  Derived  Types 

Derived  types  are  subject  to  the  same  restrictions  as  their  parent  types. 

Example:  The  following  example  illustrates  a  clearly  readable  and 
understandable  mnemonic  derived  type  declaration.  The 
package  Key_Manager_Package  is  declared  in  Section  2  -  7.4.2. 

type  Access_Key_Type  is  new  Key_Manager_Package .  Key_Type; 

—  the  derived  subprograms  have  the  following  specifications: 

—  procedure  Get_Key  (  K  :  out  Access_Key_Type  ) ; 

—  function  "<"  (  X,  Y  :  ,Access_KeyJType  )  return  BOOLEAN; 

—  function  "+"  (  X,  Y  :  Acoess_Key_Type  )  return  Access_Key_Type ; 


2  -  3.5  Scalar  Types 

No  additional  Ada-specific  impact  on  TCBs 


2  -  3.5.1  Enumeration  Types 

The  use  of  enumeration  types  can  improve  the  readability,  understandability, 
and  maintenance  of  code. 


Guideline: 

1.  An  enumeration  type  should  be  used  to  identify  a  set  of  discrete  items 
with  mnemonic  names  that  promote  their  readability  and 
understandability . 


Example:  The  following  example  illustrates  a  clearly  readable  and 
understandable  mnemonic  enumeration  type  declaration. 
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—  Security_Classification_Type  is  declared  in 

—  package  Basic  JICB_Types_Package .  Because  only  essential 

—  features  of  this  package  need  to  be  shown,  it  is  not  included 

—  formally  in  this  appendix. 

type  Security_Classificaticxi_Type  is 

(  Unclassified,  Confidential,  Secret,  Tcp_Secret  )  ; 

2  -  3.5.2  Character  Types 

No  additional  Ada-specific  impact  on  TCBs 

2  -  3.5.3  Boolean  Types 

No  additional  Ada-specific  impact  on  TCBs 

2  -  3.5.4  Integer  Types 

No  additional  Ada-specific  impact  on  TCBs 

2  -  3.5.5  Operations  of  Discrete  Types 

No  additional  Ada-specific  impact  on  TCBs 

2  -  3.5.6  Real  Types 

No  additional  Ada-specific  impact  on  TCBs 

2  -  3.5.7  Floating  Point  Types 

No  additional  Ada-specific  impact  on  TCBs 

2  -  3.5.8  Operations  of  Floating  Point  Types 
No  additional  Ada-specific  impact  on  TCBs 
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2  -  3.5.9  Fixed  Point  Types 

No  additional  Ada-specific  impact  on  TCBs 


2  -  3.5.10  Operations  of  Fixed  Point  Types 
No  additional  Ada-specific  inpact  on  TCBs 


2  -  3.6  Array  Types 

Of  all  data  types  whose  storage  is  static,  array  types  and  their  memory 
management  are  of  primary  concern  to  the  software  development  of  TCBs. 
Static  storage  is  a  portion  of  memory  that  is  set  aside  at  compile  time  and  ; 
whose  size  does  not  change  during  program  execution.  Objects  of  most  Ada 
data  types  use  static  storage.  Statically  stored  data,  like  that  in  an  ■ 

array,  can  generally  be  accessed  more  efficiently  than  data  stored 
dynamically  in  data  structures  consisting  of  access  types.  This  is  offset 
by  their  potentially  inefficient  use  of  memory;  this  is  particularly  true  of 
arrays.  It  would  be  desirable  to  include  in  the  next  revision  of  Ada 
(Ada9x)  a  predefined  pragma  that  directs  Ada  compilation  to  include  code 
that  scrubs  memory  that  is  local  to  a  subprogram  or  package  just  before  the 
scope  of  the  subprogram  or  package  is  left  during  program  execution,  i.e., 
just  before  the  visibility  of  the  static  (or  dynamic)  memory  is  lost.  These  { 

conflicting  needs,  efficient  execution  versus  efficient  use  of  memory,  are  j 

particularly  important  for  large  data  structures.  j 


Guidelines:  \ 

1.  Determine  whether  each  data  structure  should  be  implemented  for  \ 

efficient  execution  (static) ,  or  for  efficient  memory  usage  (dynamic) .  : 

This  determination  should  be  done  as  early  as  possible  in  the  j 

development  of  a  TCB  system,  preferably  in  the  TCB's  requirements 
specification. 

2.  Monitor  the  implementation  of  static  storage  during  design  reviews  and 
code  walkthroughs.  At  times  the  need  for  a  new  static  data  structure  J 
will  not  be  identified  until  design  or  coding.  The  need  for  and  use  of 
these  new  static  data  structures  also  should  be  monitored  during  design 
reviews  and  code  walkthroughs. 

3.  Static  storage  should  be  initialized  before  use  and  be  scrubbed  when 
the  data  it  contains  is  no  longer  needed.  That  is,  static  storage 
should  contain  sensitive  data  only  when  the  corresponding  static  data 
structure  is  visible  during  program  execution.  Thus,  local  static 
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storage  should  be  initialized  upon  entering  its  scope,  and  should  be 
scrubbed  just  before  leaving  its  scope. 


Examples:  The  following  examples  illustrate  clearly  readable  and 
understandable  mnemonic  array  type  declarations. 

The  following  declarations  in  this  section  are  located  in  the  array 
types  version  of  package  Aocess_Control_List_Types_Package.  Because  only 
essential  features  of  this  package  need  to  be  shewn,  it  is  not  included 
formally  in  this  appendix. 


Max_Number_of_Cto j ects  :  (constant  NATURAL  :=  25; 
Max_Nunber_of_Individuals  :  constant  NATURAL  :=  25; 
Max_Nunber_ofj3rtxps_of_Individuals  :  constant  NATURAL  :=  25; 


type  NamedjOb j  ects_List_Type  is  array 

(  POSITIVE  range  1  . .  Max_Number_of_Ob j  ects  )  of 
Basic JTCB_Types_PackageT  Name_of_0b  j  ect_Type  ?  —  see  2-4.1 

type  NamedjDb j  ects_ACL_Type  is  array 

(  POSITIVE  range  1  . .  Max_Number_of_Qb j  ects  )  of 
Named_Ob j ect_Record_Type ;  —  see  2  -  3.2.1 


type  Named_Individuals_List_Type  is  array 

(  POSITIVE  range  1  . .  Max_Nurriber_of_Individuals  )  of 
Basic_TCB_Types_Package . 

Naire_of_Individual Jiype ;  —  see  2-4.1 

type  Naited_Individuals_ACL_Type  is  array 

(  POSITIVE  range  1  . .  Max_Number_of_Individuals  )  of 
Named_lJKiividual_Record._Type ;  —  see  2  -  3.2.1 


type  Gro>ups_of_Named_Individuals_List_Type  is  array 

(  POSITIVE  range  1  . .  MaxJ^umber_of_Groups_of_Individuals  )  of 
Bas ic_TCB_Types_Package . 

Naire_of jGroup_of_Individuals_Type ;  —  see  2-4.1 

type  Groups_of_Named_Individuals_ACL_Type  is  array 

(  POSITIVE  range  1  ..  Max_Nurnber_of_Groi^is_of_Individuals  )  of 
Group_of_Named_Individuals_Record_Type ;  —  see  2  -  3.2.1 


2  -  3.6.1  Index  Constraints  and  Discrete  Ranges 
No  additional  Ada-specific  impact  on  TCBs 
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2  -  3.6.2  Operations  of  Array  Types 

No  additional  Ada -specific  impact  on  TCBs 
2  -  3.6.3  The  Type  String 

Example:  The  following  example  illustrates  a  clearly  readable  and 
understandable  mnemonic  string  type  declaration. 

—  Name_String_Type  is  declared  in  package  Eas ic_TCB_Types_Package . 

—  Because  only  essential  features  of  this  package  need  to  be  shewn, 

—  it  is  not  included  formally  in  this  appendix. 

subtype  Name_String_Type  is 

STRING  (  1  . .  Max_Named_String_Iength  ) ;  —  see  2  -  3.2.2 

For  additional  discussion  refer  to  Sections  2-3.  and  2  -  3.6. 


2  -  3.7  Record  Types 

All  restrictions  and  implications  inherent  in  the  types  of  a  component  of  a 
record  are  implicit  for  that  component. 


Guideline: 

1.  In  the  declarations  of  records,  assign  default  values  to  the  record 
components  to  avoid  reference  to  undefined  variables. 

Examples:  The  following  examples  illustrate  clearly  readable  and 
understandable  mnemonic  record  type  declarations. 

The  following  declarations  in  this  section  are  located  in 
both  the  access  and  array  types  versions  of 

package  Access_Control_List_Types_Package .  Because  only  essential 
features  of  this  package  need  to  be  shewn,  it  is  not  included  formally  in 
this  appendix. 

type  Named_Ob j  ect_Record_iype  is 
record 

Name  :  Basic_TCB_Types_Package .  Name_of_Qb j  ectjiype  —  see  2-4.1 
:=  Bas ic_TCB_Types_Package .  Blank_Name_String;  —  see  2  -  3.2.1 


024 


APPENDIX  C 

Mapping  Of  TCB  Relevant  Ada  Constructs  and  Features  To 
The  Reference  Manual  For  The  Ada  Programing  Language 


Sensitivity_Label  : 

Mandatory_Access_Control_Types_Package . 

Sensitivity_Label_Type 

:=  Marriatory_Acoess_Control_TVpes_Package. 

Scrubbed_Sensitivity_lAbe.l ;  —  see  3  -  3.1.3 

Authorized_Named_Individuals_List  : 

NamedJLndividuals_lAst_Type  —  see  2  -  3.6  and  2  -  3.8 

:=  Scrubbed_Named_Individuals_List;  —  see  2  -  3.2.1 

Authorizedj3roupsjof_Named_Irxiividuals_List  : 

—  see  2  -  3.6  and  2  -  3.8 
Groups_of_Named_Individuals_lAst_Type 
:=  Scrubbedj3rcups_of_Named_Individuals_List ;  —  see  2  ~  3.2.1 

Unauthorized_Naroed_Individuals_List  : 

Named_Individuals_List_Type  —  see  2  -  3.6  and  2  -  3.8 

:=  Scrubbed_Named_Individuals_List ;  —  see  2  -  3.2.1 

end  record; 


type  Nai^_Individual_Record_Type  is 
record 

Name  ;  Basic_TCB_Types_Package . 

Name_of_Individual_Type 
;=  Basic_TCB_Types_Package .  Blank_Name_String; 

Sensitivity_Label  ; 

Mandatory_Access_Control_Types_Package . 

Sensitivity_Iabel_Type 

:=  Mandatory_Access_Control_Types_Package. 

Scrul±)ed_Sensitivity_Iabel ;  —  see  3  -  3.1.3 


—  see  2  -  4.1 

—  see  2  -  3.2.1 


Named_Objects_List  : 

Named_Ctojects_List_Type  —  see  2  -  3.6  and  2  -  3.8 

;=  Scrubbed_Named_Ob j ects_List ;  —  see  2  -  3.2.1 

end  record; 


type  Group_o  f _Named_Individual  s_Record_Type  is 
record 

Name  :  BasicJTCBJTypes_Package. 

Name_ofjSroup_of_Individuals_Tj,pe 
:=  Bas ic_TCB_Types  __Padkage .  Blank_Name_String; 


see  2  -  4.1 
see  2  -  3.2.1 
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Sensitivity_Laoel  : 

Mandatory_Access_Control_Types_Package . 

Sensitivity_Label_Type 

:=  Mandatory_Access_Cbntrol_Types_Package. 

5crubbed_Sensitivity_Label ;  —  see  3  -  3.1.3 

Named_Ob j  ects_List  : 

Named  _Obj  ects_List_Type  —  see  2-3.6  and  2-3.8 

:=  Scrubbed_Named_Ob j ects_List ;  —  see  2  -  3.2.1 

end  record; 


2  -  3.7.1  Discriminants 

No  additional  Ada-specific  inpact  on  TCBs 


2  -  3.7.2  Discriminant  Constraints 

No  additional  Ada-specific  inpact  on  TCBs 


2  -  3.7.3  Variant  Parts 

No  additional  Ada-specific  inpact  on  TCBs 


2  -  3.7.4  Operations  of  Record  Types 

No  additional  Ada-specific  inpact  on  TCBs 


2  -  3.8  Access  Types 

The  access  type  in  Ada  is  roughly  equivalent  to  the  pointer  type  in  Pascal 
in  that  it  is  used  to  create  and  manage  dynamic  storage. 

Dynamic  storage  is  a  pool  of  memory,  or  heap,  that  is  used  for  storing  data 
whose  demand  for  memory  varies  during  program  execution.  It  is  a  useful 
mechanism  that  can  provide  a  convenient  and  flexible  means  of  managing 
memory  when  the  need  for  memory  is  constantly  changing. 

Access  types  are  used  in  Ada  to  implement  dynamic  storage  constructs,  like 
linked  lists  and  queues,  which  are  convenient  ways  of  managing  a  given 
system’s  continually  varying  demands  for  memory.  "An  implementation  may 
(but  need  not)  reclaim  the  storage  occupied  by  an  object  created  by  an 
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allocator,  once  this  object  has  became  inaccessible"  [ANSi/>a]j-STD-i815A- 
1983] .  In  addition,  Ada  has  the  pragma  CONTROLLED,  which  "specifies  that 
automatic  storage  reclamation  must  not  be  performed  for  objects  designated 
by  values  of  the  access  type,  except  upon  leaving  the  innermost  block 
statement,  subprogram  body,  or  task  body  that  encloses  the  access  type 
declaration,  or  after  leaving  the  main  program"  [ANSI/MD>SID-1815A~19833. 
Also,  "if  an  object  or  one  of  its  subccrponents  belongs  to  a  task  type,  it 
is  considered  to  be  accessible  as  long  as  the  task  is  not  terminated," 
Ada's  access  types  can  promote  an  Ada  TCB  system's  design,  implementation, 
arri  maintenance. 


Guidelines: 

1.  Determine  whether  each  data  structure  should  be.  implemented  for 
efficient  memory  usage  (dynamic) ,  or  for  efficient  execution  (static) , 
This  determination  should  be  done  as  early  as  possible  in  the 
development  of  a  TCB  system,  preferably  in  the  TCB's  requirements 
specification. 

2.  Avoid  using  access  types  and  their  corresponding  objects  in  areas  where 
aliasing  might  occur  in  parameter  passing. 

3.  Avoid  using  access  types  in  task  types.  The  reason  for  this  is 
twofold:  1.  To  prevent  the  dynamic  creation  of  tasks.  2.  The  lack  of 
experience  with  and  understanding  of  passing  tasks  as  parameters  in 
subprogram  cal3.s. 

4.  Monitor  the  implementation  of  dynamic  storage  during  preliminary  and 
detailed  design  reviews  and  code  walkthroughs.  At  times  the  need  for  a 
new  dynamic  data  structure  will  not  be  identified  until  design  or 
ceding.  The  need  for  and  use  of  these  new  dynamic  data  structures  also 
should  be  monitored  during  preliminary  and  detailed  design  reviews  and 
cede  walkthroughs. 

5.  The  TCB's  dynamically  stored  data  that  is  about  to  be  collected  by 
Ada's  garbage  collection  should  be  protected  by  deleting  the  data  just 
before  it  is  collected  as  garbage.  That  is,  sensitive  data  that  may  be 
accessed  mast  be  removed  from  memory  before  the  memory  is  deallocated. 
Also  memory  should  be  scrubbed  just  before  it  is  dynamically  allocated 
with  Ada's  new  statement.  These  additional  checks  will  impinge  on 
system  performance. 

6.  Avoid  aliasing  that  can  be  introduced  with  access  types.  Minimize  the 
number  of  aooess  type  objects  that  point  to  any  node  [ASOS  1987]. 
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7.  Avoid  using  the  pragma  CONTROLLED.  Any  use  of  the  pragma  CONTROLLED 
should  be  reviewed  during  design  reviews  and  code  walkthroughs. 


Examples:  The  following  examples  illustrate  clearly  readable  and 
understandable  mnemonic  access  type  declarations.  To  ensure  that 
the  memory  allocated  to  a  node  is  scrubbed,  the  components  of  a 
node's  record  type  should  be  initialized  to  scrubbed  values,  as 
shewn  below.  Also,  ensure  that  a  node  record  is  set  to  scrub 
values  before  it  is  placed  back  in  the  heap,  i.e. ,  before  nothing 
points  to  it  any  longer. 

The  following  declarations  in  this  section  are  located  in  the  access 
types  version  of  package  Acxess jDantrol JListJTypes_Package .  Because  only 
essential  features  of  this  package  need  to  be  shown,  it  is  not  included 
formally  in  this  appendix. 

type  NamedjDb j  ects_List_Type ; 
type  NamedjDb  j  ecte JDlst_Pointer Jiype 
is  access  Named_Qb  j  ects_List_Type ; 

type  NamedjDb j  ects_List_Type  is 
record 

Name  :  BasicJTCBJiypes_Package . 

Name_of  jOb j ectJType  —  see  2  -  4.1 

:=  Basic jTCB_Types_Package. 

BlankJName_String;  —  see  2  -  3.2.1 

Next  :  NamedjDb  j  ec±s_Iist_Po  inter JType  :=  null; 
end  record; 


type  NaredjDbjects_ACTj_TVpe; 
type  NamedjDbjects_AOj_PointerJiype 
is  access  NamedjDb  j  ects_ACL_Type  ; 

type  NamedjDb  j  ects_ACL_Type  is 
record 

Named JDbj  ect_ACL_Record  : 

NamedjDbj ect_Record_Type 

:=  Scrubbed_NamedjDbj ect_ACL_Record ;  —  see  2  -  3.2.1 

Next  :  Named_Ob j  ec.^_ACL_PointerJiype 
:=  null; 
end  record; 
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type  Named_Individuals_List_Type 
type  Narcd_Individuals_List_Poiriter_Type 
is  access  Named_Individual  s_List_Type ; 

type  Naiied_Individuals_List_Type  is 
record 

Name  :  Basic_TCB_Types_Package . 

Name_of_Irdividual_Type  —  see  2-4.1 

:=  Basic_TCB_Types_Package . 

Blank_Name_Strir*g;  —  see  2  -  3.2.1 


Next  :  Na]red_Individuals_List_Pointer_Type  :=  null; 
end  record; 


type  Named_Individuals_ACL_Type ; 
type  Named_Individuals_ACL_Pointer_Type 
is  access  Named_Individuals_ACL_Type ; 

type  Named_Irdividuals_Aaj_TVpe  is 
record 

Named_Individual_ACL_Record  : 

NaroedJErriividualJReoordJType 

:=  SonahbedJNam0d_Individual_ACL_Record ;  —  see  2  -  3.2.1 

Next  :  Named_Individua?v.s_AOJ_Pointer_Type 
:=  null? 
end  record; 


type  Groups_of_Named_Individuals_List_Type 
type  Gro\ps_of_Named_Individuals_List_Pointer_Type 
is  access  Groi^_ofJ^amed_Individuals_List_Type; 

type  Graupsjof_Nam9d_3jr3ividualsJListJType  is 
record 

Name  :  BasicJTCB_Types_Package. 

Name_of_Gro-ap_of_Individuals_Type  ; 

:=  Basic_TCB_Types_Package . 

Blank_Name_Strir»g ; 


—  see  2 

—  see  2 


4.1 

3.2.1 


PwMw\<-i  M-swi/vJ  c  T  i  cf  Dr«i  n4-c>* 

NJi.  11UIIICU  Xi  /VAX  V  J.'tAUUJ.ta'  111^^  i.  V JJ  i j  ^ 


:=  null; 
end  record; 
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type  Groups jDf_Named_lndividuals_ACLJlype; 
type  Groups_of_Nan^_Individuals_ACL_Pointer_Type 
is  access  Groups_of_Named_Individuals_ACL_Type ; 

type  Groups_of_Named_Irdividuals_ACL_Type  is 
reoard 

Group_of_Named_Individual  s_ACL_Record  : 
Group_of_Named__Individuals_Record_Type 
:=  ScrubbedjlroupjDf_Naii^_Individuals_ACL_Record ; 

—  see  2  -  3.2.1 

Next  :  Grocps_of_Na^^_Individuals_ACL_Pointer_Type 
:=  null; 
end  record; 


2  -  3.8.1  Inocoplete  Type  Declarations 

No  additional  Ada-specific  inpact  on  TCBs 


2  -  3.8.2  Operations  of  Access  Types 

No  additional  Ada-specific  inpact  on  TCBs 


2  -  3.9  Declarative  Parts 

No  Ada-specific  inpact  on  TCBs 
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2-4.  Names  and  Expressions 

This  chapter  of  the  URM  discusses  the  use  of  identifiers  as  names,  examining 
names  into  expressions,  and  rules  for  evaluation  of  both  names  and 
expressions.  The  areas  of  primary  interest  to  the  development  of  TCBs  are 
Names  (Section  2  -  4.1)  and  Allocators  (Section  2  -  4.8). 


4.1  Names 

The  selection  of  names  can  promote  the  code’s  readability, 
understandability,  and  maintenance. 

Guidelines: 

1.  Name  data  types  and  objects  with  clearly  readable  and  understandable 
mnemonics. 

2.  Any  data  item  or  group  of  data  should  have  its  own  symbolic  name  that 
promotes  its  readability  and  understandability  [ASOS  1987]. 

Examples:  The  following  examples  illustrate  clearly  readable  and 
understandable  mnemonic  names. 

The  following  type  declarations  in  this  section  are  located  in 
package  Basic_TCB_Types__Package.  Because  only  essential  features  of  this 
package  need  to  be  shown,  it  is  not  included  formally  in  this  appendix. 

subtype  Name_of_Ob j ect_Type  is  Name_String_Type;  —  see  2  -  3.2.2 

Name_of_Ob j  ect  :  Name_of_Object_Type 

;=  Blank_Name_String;  —  see  2  -  3.2.1 


subtype  Name_of_Individual_Type  is  Name_Strir>g_Type;  —  see  2  -  3.2.2 

Name_of_Individual  :  Name_of_Individual_Type 

:=  Blank_Name_String;  —  see  2  -  3.2.1 


subtype  Name_of_Grcup_of_Individuals_Type  is  Name_String_Type; 


—  see  2  -  3.2.2 


Naie_of_Gro'up_of_Naitied_Ir»aiViuUais  ; 
Narre_of__Group_of_Individuals_TVpe 
:=  Blank  Name  String; 


see  2  -  3.2.1 
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1  -  4.1.1  Index  Canponerrts 

No  additional  Ada-specific  inpact  on  TCBs 

2  -  4.1.2  Slices 

No  additional  Ada-specific  inpact  on  TCBs 

2  -  4.1.3  Selected  Oaapcnents 

No  additional  Ada-specific  inpact  on  TCBs 

2  -  4.1.4  Attributes 

No  additional  Ada-specific  inpact  on  TCBs 

2  -  4.2  literals 

No  Ada-specific  in^ct  on  TCBs 

2  -  4.3  Aggregates 

No  Ada-specific  inpact  on  TCBs 

2  -  4.3.1  Record  Aggregates 

No  Ada-specific  inpact  on  TCBs 

2  -  4.3.2  Array  Aggregates 

No  Ada-specific  inpact  on  TCBs 

2  -  4.4  Expressions 

No  Ada-specific  impact  on  TCBs 
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2-4.5  Operators  and  Expression  Evaluation 
No  Ada-specific  impact  on  TCBs 

2  -  4.5.1  Logical  Operators  and  Short-Circuit  Oontzol  Forms 

No  Ada-specific  impact  on  TCBs 

2  -  4.5.2  Relational  Operators  and  Membership  Tests 
No  Ada-specific  impact  on  TCBs 

2  -  4.5.3  Binary  Adding  Operators 
No  Ada-specific  impact  on  TCBs 

2  -  4.5.4  Unary  Adding  Operators 

No  Ada-specific  impact  on  TCBs 

2  -  4.5.5  Multiplying  Operators 

No  Ada-specific  impact  on  TCBs 

2  -  4.5.6  Highest  Precedence  Operators 
No  Ada-specific  impact  on  TCBs 

2  -  4.5.7  Accuracy  of  Operations  with  Real  Operands 
No  Ada-specific  impact  on  TCBs 

2  -  4.6  Type  Conversions 

The  use  of  type  conversion  violates  data  abstraction,  by  confusing  the 
meaning  of  objects  whose  types  are  converted. 
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Guideline: 

1.  Avoid  using  type  conversion  in  implementing  a  TCB  system. 

2.  Security  aspects  of  the  use  of  type  conversion  should  be  reviewed 
during  design  reviews  and  code  walkthroughs. 

2-4.7  Qualified  Expressions 

No  Ada-specific  inpact  on  TCBs 


2  -  4.8  Allocators 


Guidelines: 

1.  Ensure  that  when  using  allocators  the  initialization  recommendations 
(Section  2  -  3.2.1)  are  taken  into  consideration.  This  will  prevent 
programs  from  operating  on  objects  that  are  not  initialized. 

2.  Minimize  using  allocators.  Refer  to  Section  2  -  3.8  for  further 
discussion  of  access  types. 


2-4.9  Static  Expressions  and  Static  Subtypes 
No  Ada-specific  inpact  on  TCBs 
2  -  4.10  Universal.  Expressions 

No  Ada-specific  inpact  on  TCBs 
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2-5.  Statements 

This  chapter  of  the  LRM  describes  the  eight  types  of  Ada  statements.  These 
are  assignment  (with  special  case  for  arrays) ,  conditional  (if) ,  case,  loop, 
block,  exit,  return,  and  goto.  For  the  most  part,  these  are  the  standard 
kinds  of  statements  found  in  most  modem  day  programing  languages. 


2  -  5.1  Sinple  and  Ccnpound  Statements  -  Sequences  of  Statements 


Guidelines: 

1.  Statements  should  satisfy  the  following  criteria:  (1)  no  aliasing,  (2) 

no  side  effects,  and  (3)  no  nonlocal  variables.  These  criteria  are 
good  software  engineering  practice,  and  as  such  should  not  require 
extra  programming  effort.  These  criteria  are  necessary  in  that  each  of 
them,  if  not  met,  may  cause  an  unintended  change  to  be  affected  during 
the  course  of  the  program  execution.  These  unintended  changes  may 
cause  an  erroneous,  or  at  least,  unexpected,  result. 

2.  Ada  statement  semantics  should  support  the  general  goals  of  program 
clarity  and  unambiguous  execution  [ASOS  1937] . 


2  -  5.2  Assignment  Statement 

No  Ada-specific  impact  on  TCBs 


2  -  5.2.1  Array  Assignments 

No  Ada-specific  impact  on  TCBs 


2-5.3  If  Statements 

In  compound  if  statements,  the  compiler's  order  of  evaluation  could  cause 
side  effects. 

Guideline: 

1.  The  order  of  evaluation  in  compound  if  statements  must  be  forced  by 
using  the  short  circuit  forms,  and  then  and  or  else. 
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1  -  5.4  Case  Statements 

The  use  of  the  others  choice  may  allow  an  error  that  would  have  been  caught 
at  ccnpile  time.  For  example,  if  the  "alternative"  expression  is  an 
enumeration  type  that  was  expanded  and  if  the  additional  cases  were  not 
added  to  the  case  statement,  then  the  case  statement  would  not  ccttpile  if 
the  others  choice  were  not  used. 

Guideline: 

1.  Avoid  using  the  others  choice  in  case  statements,  particularly,  when 
the  "alternative"  expression  is  an  enumeration  type. 


2  -  5.5  loop  Statements 

No  Ada-specific  inpact  on  TCBs 


2  -  5.6  Block  Statements 

No  Ada-specific  impact  on  TCBs 


2  -  5.7  Exit  Statements 

No  Ada-specific  impact  on  TCBs 


2  -  5.8  Return  Statements 

The  leaving  of  a  subprogram  or  accept  statement  needs  to  be  clearly 
traceable  to  a  single  return  statement. 

Guideline: 

1.  All  subprograms  and  accept  statements  should  have  a  single  return 
statement  for  leaving  their  scope  of  execution. 


2  -  5.9  Goto  Statements 

Goto  statements  provide  the  means  for  a  program  to  transfer  control,  in  an 
unstructured  manner,  of  its  operation  elsewhere  in  the  program.  The  larger 
the  module,  the  more  potential  problems  that  goto  statements  can  present. 
In  particular,  undesired  redirection  of  program  execution  may  be  inserted 
that  is  hard  to  track.  Because  this  transfer  of  control  may  be  unregulated, 
ensuring  the  security  of  a  TUB  system  is  very  difficult.  Also,  Ada  provides 
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more  structured  control  structures  (e.g. ,  for  and  while  loops)  that  make 
losing  goto  statements  unnecessary. 


Guidelines: 

1.  Avoid  using  Goto  statements  in  any  system  implementation ,  especially 
that  of  a  TCB. 

2.  Security  aspects  of  proposed  goto  statements  should  be  addressed  as 
early  as  possible  in  the  development  of  a  TCB  system,  preferably  in  its 
preliminary  and  detailed  design  phase. 

3.  Security  aspects  of  all  goto  statements  should  be  reviewed  during 
design  reviews  and  code  walkthroughs. 
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2-6.  Subprograms 

•mis  chapter  of  the  LEM  defines  the  mechanism  for  describing  subprograms 
(technically,  procedures  and  functions) ,  the  mechanisms  for  their 
invocation,  and  the  manner  of  parameter  passing.  In  the  absence  of 
concurrency,  as  with  other  aspects  of  the  Ada  language,  most  aspects  of 
subprogram  declaration  and  invocation  are  equivalent  with  respect  to  other 
languages.  Sane  specific  differences  that  are  relevant  to  Ada  are  the 
issues  of  subprogram  declarations  (Section  2  -  6.1),  formal  parameter  mcdes 
(Section  2  -  6.2),  and  parameter  "aliasing"  (Section  2  -  6.4). 

Guidelines: 

1.  Subprograms  should  have  only  one  entry  point  and  only  one  exit  point  to 
promote  testing  and  maintaining  the  subprograms. 

2.  Avoid  side  effects  in  subprograms,  e.g. ,  on  global  data  (non-parameter 
data) ,  by  reference  to  as  well  as  modifying  the  global  data  within  a 
subprogram  [ASOS  1987]. 

3 .  Avoid  creating  large  subprograms  because  thoroughly  testing  large 
subprograms  is  more  difficult  than  testing  small  subprograms.  That  is, 
avoid  creating  subprograms  with  a  larger  number  of  possible  logical 
paths  (i.e. ,  transfers  of  control  of  program  execution) ,  which  is 
typical  in  large  subprograms.  The  use  of  a  large  subprogram  should  be 
justified  in  the  preliminary  and  detailed  design  reviews  and  code 
walkthroughs. 

4.  No  subprogram,  and  especially  no  large  subprogram,  should  contain  goto 

statements.  The  use  of  a  goto  statement  should  be  justified  in 

preliminary  and  detailed  design  reviews  and  code  walkthroughs. 


2-6.1  Subprogram  Declarations 

Equivalently  named  subprograms  with  the  same  parameter  type  profile  are 
allowed  because  the  scopir a  rules  in  Ada  clearly  define  which  subprogram  is 
visible  at  any  point  in  the  program  text. 


Guideline: 

1.  Justify  equivalently  named  subprograms  from  a  human  viewpoint  because 
the  additional  caigplexity  of  overloaded  names  could  cause  difficulty  in 
the  software  development  process.  The  equivalent  turning  of  subprograms 
should  be  monitored  during  preliminary  and  detailed  design  reviews  and 
code  walkthroughs. 
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2-6.2  Formal  Parameter  Modes 


Guideline: 

1.  Include  the  definition  of  the  default  values  for  out  parameters,  akin 
to  that  described  in  Section  2  -  3.2.1  for  abject  declarations.  Doing 
so  helps  to  prevent  erroneous  programs. 


2  -  6.3  Subprogram  Bodies 

Data  present  in  the  data  objects  declared  within  a  subprogram  remains  in  the 
memory  containing  the  subprogram's  activation  record  after  program  execution 
has  left  the  subprogram.  Therefore  the  data  should  be  scrubbed  from  the 
memory  just  before  the  scope  of  the  subprogram  is  left. 


Guideline: 

1.  Scrub  data  present  in  the  data  objects  declared  within  subprograms 
before  returning  from  a  subprogram's  call. 


2  -  6.3.1  Conformance  Buies 

No  additional  Ada-specific  impact  on  TCBs 


2  -  6.3.2  Inline  Expansion  of  Subprograms 

No  additional  Ada-specific  impact  on  TCBs 


2  -  6.4  Subprogram  Calls 

No  additional  Ada-specific  impact  on  TCBs 


2  -  6.4.1  Parameter  Associations 


Guideline: 

1.  Aliasing  across  subprogram  boundaries  must  be  minimized.  Harmful 
aliasing  may  occur  when  formal  parameters  are  assumed  to  represent 
distinct  variables,  but  actual  parameters  supplied  are  not  distinct 
[ASOS  1987]. 
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2  -  6.4.2  Default  Parameters 
Guidelines: 

1.  Use  named  parameter  association  to  improve  readability  and 
understandability  of  subprogram  calls. 

Example:  Ibis  example  illustrates  named  parameter  association. 

procedure  Search_File  (  File  :  in  out  Access_Control_  Li st_Types_Package . 

ACL_File_Type ; 

Key  :  in  Name; 

Index  :  out  File_Index  ) ; 

Search  File  (  File  =>  Named  Objects  Access  Control  List  Manager  Package. 

ACL_File, 

Key  =>  "Smith  ,  J", 

Index  =>  Record_Entry  ) ; 

2.  Default  parameters  may  be  used  when  a  subprogram  has  parameters  whose 
actual  values  do  not  change  over  most  calls. 

Example:  This  example  from  package  TEXT_IO  illustrates  default  parameters. 

procedure  CREATE  (  FILE  :  in  out  FILSJIYFE; 

MODE  :  in  FILE_MDDE 

NAME  :  in  STRING 

FORM  :  in  STRING 

TEXT  10.  CREATE  (  FILE  =>  Named  Objects  Access  Control  List  Manager  Package. 

ACL_File  ) ; 


2  -  6.5  Function  Subprograms 

Function  subprograms  should  be  truly  functional,  which  is  determined  by  the 
following  two  guidelines. 


=  OUTJETIE; 

—  III!  . 

—  / 

—  1111  \  • 


Guidelines: 

1.  Prohibit  functions  from  containing  either  input  or  output  operations 
(Chapter  14  of  the  LKM)  to  be  consistent  with  the  fundamental 
characteristics  of  functions,  i.e.,  to  return  only  a  single  value  [ASOS 
1987] . 

2.  Function  subprograms  should  not  reference  any  nonlocal  (i.e.,  global) 
variables. 
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6.6  Parameter  and  Result  Type  Profile  -  Overloading  of 


For  the  discussion  of  overloading  refer  to  Section  2  -  6.1. 


6.7  Overloading  of  Operators 

For  .the  discussion  of  overloading  refer  to  Section  2  - 
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2-7.  Packages 

This  chapter  of  the  LRM  discusses  with  the  specification  of  packages  as  a 
means  to  encapsulate  data  and  subprograms  into  a  single  structure.  The  use 
of  packages  directly  supports  the  notion  of  abstract  data  types,  a  common 
mechanism  in  software  engineering  used  to  reduce  program  complexity.  Hie 
following  software  engineering  principles  are  discussed  in  this  section: 
data  abstraction,  information  hiding,  modularity,  and  localization. 
Compilation  of  specifications  is  discussed  in  Package  Specifications  and 
.Declarations  (Section  2-7.2). 

Ada's  data  abstraction  mechanisms  are  well  suited  to  represent  the  data 
objects  in  a  system's  design,  namely,  that  of  a  TCB.  They  serve  the 
conceptual  manipulation  of  the  data  objects  in  a  relatively  high-level  of 
abstraction  without  regard  to  their  underlying  representation .  Ada  allows 
data  to  be  abstracted  with  abstract  data  types.  An  abstract  data  type  is  a 
construct  that  "denotes  a  class  of  objects  whose  behavior  is  defined  by  a 
set  of  values  and  a  set  of  operations"  [Boodh  1987A,  p.613].  Ada's  two 
primary  features  that  promote  the  creation  of  abstract  data  types  are  its 
strong  data  typing  facilities  (which  is  discussed  above)  and  its  packaging 
mechanism.  A  package  can  be  used  to  define  an  abstract  data  type  by 
encapsulating  its  underlying  data  types  and  the  operations  associated  with 
the  abstract  data  type.  Using  Ada's  data  abstraction  techniques  aids  the 
representation  of  data  objects  in  the  problem  space  of  any  system,  including 
a  TCB.  "Abstraction  aids  in  the  maintainability  and  understandability  of 
systems  by  reducing  the  details  a  developer  needs  to  knew  at  any  given 
level"  [Booch  1987B,  p.33] .  This  sound  software  engineering  technique  car. 
promote  an  Ada  TCB  system's  design,  implementation,  and  maintenance. 


Guidelines: 

1.  Use  packages  to  enforce  visibility  rules  of  data  accessibility  [ASOS 
1987]. 

2.  Use  Ada's  data  abstraction  mechanisms  to  represent  data  objects  in  a 
TCB  system's  design.  Identify  and  implement  abstract  data  types  in  the 
design  by  encapsulating  them  in  packages.  That  is,  the  package 
specification  should  contain  an  abstract  data  type  declared  as  a 
(limited)  private  type,  and  those  operations  that  can  be  performed  on 
objects  of  this  abstract  data  type.  No  direct  access  to  data 
structures  encapsulated  by  such  packages  should  be  allowed,  i.e. , 
access  to  these  data  structures  should  be  performed  indirectly  through 
the  operations  provided  in  the  package  specification. 

3.  Data  objects  should  be  created  using  Ada's  strong  data  typing 
facilities  and  its  packaging  mechanism,  which  promote  the 
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understandabil  ity ,  maintainability,  and  reusability  of  a  system's 
design  and  code. 

4.  Ihe  fundamental  data  abstractions  should  be  identified  early, 
preferably  during  the  TCB  system's  requirements  specification.  Their 
implementation  should  be  monitored  during  preliminary  and  detailed 
design  reviews  and  code  walkthroughs. 


Ada's  information  hiding  facilities  complement  its  data  abstraction 
capabilities.  Whereas  abstractions  extract  the  essential  details  of  a  given 
level,  "the  purpose  of  hiding  is  to  make  inaccessible  certain  details  that 
should  not  affect  other  parts  of  a  system"  [Ross,  Gkxxdenough,  and  Irvine 
1975,  p.67] .  "Information  hiding  therefore  suppresses  how  an  object  or 
operation  is  implemented,  and  so  focuses  our  attention  on  the  higher 
abstraction"  [Booch  1987B,  p.33] .  Two  Ada  constructs  that  are  well  suited 
for  implementing  information  hiding  are  packages  and  private  types. 
"Packages  can  be  used  to  hide  information  from  the  rest  of  the  program  while 
making  explicit  the  interface  with  other  program  parts.  This  has  the 
advantage  that  implementation  details  of  each  package  can  be  changed  by 
altering  only  its  body,  and  that  the  rest  of  the  program  may  be  understood 
without  reference  to  these  details"  [Nissen  and  Wallis  1984,  p.122]. 

Hiding  the  information  about  the  implementation  of  the  data  abstraction  of  a 
data  object  is  achieved  in  Ada  by  encapsulating  the  abstraction  in  a 
package,  i.e. ,  by  hiding  the  implementation  of  the  object  and  controlling 
access  to  the  object  so  as  to  encourage  and  enforce  the  abstraction.  This 
typically  is  done  with  the  use  of  private  types  and  limited  private  types. 
In  particular,  Ada's  private  types  enable  the  focus  to  be  placed  on  higher- 
level  real-world  abstractions  rather  than  on  the  details  of  an 
implementation.  The  following  implicit  operations  may  be  performed  on 
private  types:  assignment,  tests  of  equality  and  inequality,  explicit  type 
conversion,  membership  tests,  type  qualification,  and  the  use  of  selected 
components  for  the  selection  of  any  of  the  private  type's  discriminant.  For 
limited  private  types,  though,  only  those  operations  defined  in  the 
corresponding  package  specification  are  allowed.  "Private  types  prevent 
misuse  of  structures  by  users,  presenting  them  only  with  the  abstract 
operations  appropriate  for  the  abstractions  involved"  [Nissen  and  Wallis 
1984,  p.131] .  For  more  detailed  information  on  private  types,  refer  to  the 
Ada  language  reference  manual  [ANSI/MILrSTI>1815A-1983] . 

An  example  of  using  Ada's  information  hiding  (ana  data  abstraction)  would  be 
to  implement  a  package  that  defined  a  linked  list  structure.  Only  those 
details  required  by  a  user  of  the  linked  list  package  would  be  provided  in 
the  package  specification  (data  abstraction),  e.g.,  the  operations  allowed 
on  the  linked  list.  The  implementation,  though,  of  the  linked  list  would  be 
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hidden  inside  tne  package  body,  me  user  of  the  package  does  not  need  to 
knew  hew  the  linked  list  is  implemented;  therefore,  information  on  its 
implementation  is  hidden  from  the  user. 

The  understandability  of  systems  are  enhanced  "when,  at  each  level  of 
abstraction,  we  permit  only  certain  operations  and  prevent  any  operations 
that  violate  our  logical  view  of  that  level”  [Booch  1987B,  p.33].  Thus, 
this  sound  software  engineering  technique  can  promote  an  Ada  TCB  system's 
design,  implementation,  and  maintenance. 

Guidelines: 

1.  As  much  as  possible  of  the  implementation  detail  should  be  hidden  in 
the  body  of  the  package  that  corresponds  to  an  abstract  data  type. 
That  is,  Ada's  information  hiding  facilities  should  be  used  to 
complement  its  data  abstraction  capabilities  by  making  inaccessible 
certain  details  that  should  not  affect  (i.e. ,  be  visible  to)  other 
parts  of  a  system.  The  use  of  information  hiding  should  serve  to 
minimize  the  compromising  of  the  system's  software  design  and 
structure.  That  is,  it  should  localize  logically  related 
implementation  details  of  the  abstract  data  type,  and  thus  minimize 
coupling  and  maximize  cohesion  in  the  system. 

2.  Information  hiding  should  be  implemented  with  the  two  Ada  constructs, 
packages  and  private  types.  This  implementation  should  be  monitored 
during  preliminary  and  detailed  design  reviews,  and  code  walkthroughs. 

3.  The  underlying  data  structures  that  constitute  an  (abject  of  an  abstract 
data  type  should  not  be  directly  accessible.  That  is,  the  data 
structures  should  be  accessible  only  indirectly  through  the  subprograms 
specified  in  the  object's  package  specification,  that  define  the 
operations  available  to  be  performed  on  the  object. 


Modularity  provides  the  mechanism  for  collecting  logically  related 
abstractions.  It  is  used  to  create  the  structure  of  an  object  that  makes 
the  attainment  of  some  purpose  easier.  Modularity  is  purposeful 
structuring,  which  is  usually  achieved  in  a  large  system  by  decomposing  the 
system  top-down  with  modules  that  are  either  functional  (procedure-oriented) 
or  declarative  (object-oriented)  [Booch  1987B,  p.34].  It  is  composed 
preferably  of  existing  reusable  bottem-up  software  components.  This 
structuring  should  be  performed  to  minimize  the  coupling  between  modules 
(i.e.,  minimizing  dependencies  between  modules),  and  to  strengthen  the 
cohesion  within  modules  (i.e.,  the  components  of  a  given  module  are 
functionally  and  logically  dependent)  [Booch  1987B,  p.34j. 
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Localization  is  the  collecting  of  logically  related  computational  resources 
in  one  physical  module  that  is  sufficiently  independent  of  other  modules. 
Localization  thus  helps  to  create  modules  that  exhibit  loose  coupling  and 
strong  cohesion. 

The  principles  of  modularity  and  localization  directly  support  modifiability 
and  understandability  [Booch  1987B,  p.34].  Any  given  module  should  be 
understandable  and  relatively  independent  of  other  modules.  Design 
decisions  localized  in  given  modules  limit  the  effects  of  a  modification  to 
a  small  set  of  modules.  Thus,  the  use  of  modularization  that  limits  the 
interconnections  among  program  modules,  and  the  localizing  of  logically 
related  resources  into  modules  are  sound  software  engineering  techniques 
that  can  promote  an  Ada  TCB  system's  design,  implementation,  and 
maintenance. 

Guidelines: 

1.  Name  packages  and  subprograms  with  clearly  understandable  and  readable 
mnemonics. 

2.  Use  modularization  and  localization  to  create  packages  and  their 
subprograms  so  that  they  exhibit  loose  coupling  between  the  subprograms 
and  packages,  and  exhibit  strong  cohesion  within  their  respective 
implementations.  In  contrast  to  modularizing,  logically  related 
computational  resources  should  be  localized  by  collecting  them  into  a 
package  and  its  subprograms.  Localize  design  decisions  in  packages  and 
subprograms  to  minimize  rippling  side  effects  of  a  modification  to  a 
small  set  of  modules. 

3.  Logically  related  data  abstractions  should  be  collected  into  a  class  of 
packages. 

4.  Modularity  and  localization  should  be  evaluated  during  preliminary  and 
detailed  design  reviews  and  code  walkthroughs. 


2  -  7.1  Package  Structure 

No  additional  Ada-specific  impact  on  TCBs 


2-7.2  Package  Specifications  and  Declarations 

Ada  provides  the  ability  to  compile  package  specifications  during  the  design 
stage  of  system  development.  This  aids  in  the  early  checking  of  the  system 
requirement  specifications  and  design,  e.g.,  checking  the  relationships  and 
interactions  between  modules  before  system  development  progresses  into  the 
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coding  stage.  Thus,  the  quality  of  the  requirement  specifications  and 

design  is  promoted  by  using  package  specification  compilation. 

Guidelines: 

1.  Package  specifications  should  be  compiled  during  the  design  stage  of 
Ada  system  development  to  check  the  consistency  and  quality  of  the 
design. 

2.  The  system  requirement  specifications  and  design  process  should  use 
this  capability  to  check  the  relationships  and  interactions  between 
modules  before  system  development  progresses  into  the  coding  stage. 

3.  In  package  specification  documentation  include  the  specification  of  the 
effects  produced  by  each  subprogram  defined  in  the  package  [ASOS  1987]. 


Example:  This  example  illustrates  data  abstraction,  information  hiding, 

modularity,  and  localization  achieved  with  package  specification 
and  declarations. 

with  Basic_TCB_Types_Package; 

with  AocessjCTxttrolJListJiypes_Backage; 

package  Named_Ob  j  ec±s_Acoess_OcxTtrcl_Liist_Manager_Package  is 


procedure  Get_Named_Ob  j  ect_ACL_Record 

(  Name_of_Object  :  in  Basic_TCB_Types_Packr1ge . 

Naire_of_Qb  j  ect_Type ;  —  see  2-4.1 

NaraedJDfoject_ACL_Reoord  :  out 
Acx3ess_Control_List Jiypes_Package . 

Named_Qb  j  ect_Record_Type  )?  —  see  2-4.1 

procedure  Inser^_Named_Ob  j  ect_ACL_Record 
(  Named_Ob j  ect._ACL_Record  :  in  ~ 

Aaoess_Ctorrbrol_List_Types_Package . 

Named_Ob  j  ect JRecord_Type  ) ;  —  see  2-4.1 


procedure  Delete_Named_Ob  j  ec±_ACL_Recorti 

(  NamejofObject  :  in  Bas  icJICBJiypes_Package . 

Name_of_Ob j ectjiype  ) ;  —  see  2  -  4.1 


Overflcw_AccessjCraTtrol_List  :  exception; 
AcoessjOcntrol_List_is_Null  :  exception; 
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end  Namedjubjects_Aa3essjOontrol_List_Manager_Pacikage; 


package  body  NamedjDbjec±s_Aa3essjCtontrolJjist_Manager_Package  is 

—  By  declaring  the  Named_Ob  j ects_ACL  (see  2  -  12.4)  in  the 

—  body  of  this  package  rather  than  in  the  specification, 

—  it  is  hidden  from  the  user  of  this  package.  Thus,  the  user 

—  can  gain  only  indirect  access  to  it  through  the  subprograms 

—  declared  in  the  specification.  The  typical  list  manipulation 

—  operations  (  e.g. ,  as  illustrated  by  Booch  1987A  and 
—  Feldman  1985  )  are  only  provided  in  the  package  body. 


—  Typical  list  manipulation  operations 


procedure  Get_Named_Ob j  ect_ACL_Record 

(  Name_of_Cbject  :  in  BasicJTCBJiypesJPacikage. 

NamejofjDb j ect_Type ;  —  see  2  -  4.1 

NamedjDb  j  ect_ACL_Record  :  out 
AooessjDontrol JList Jiypes JPacikage . 

Named_Object_Reoord_Type  )  is  —  see  2-4.1 


begin  —  Get_Named_Ob j  ect_ACL_Record 


—  Sequence  through  the  NamedjDb j  ect_ACL  using  the  typical 

—  list  manipulation  operations  to  locate  and  get  the 

—  indicated  Named_Ob j  ect_ACLJRecord . 


end  Get_Named_Ob j  ect_ACL_Record ; 
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procedure  Insert_Named_Ob j  ect_ACL_Record 
(  Named_Ob j  ect_ACL_Record  :  in 

Aosess_Ctyrtrol_List_Types_Packckge . 

Named_0b  j  ect_Record__Type  )  is  —  see  2-4.1 


begin  —  Insert_Naned_Ob j  ec±_ACL_Record 


—  Sequence  through  the  NamedjOb j ect_ACL  using  the  typical 

—  list  manipulation  operations  to  locate  the  appropriate 

—  place  to  insert  the  indicated  Named_Qb j  ect_ACL_Record . 

—  This  location  is  determined  by  a  predefined  mechanism, 

—  e.g. ,  alphabetizing  by  the  Named_Ob j ect_A(X_Record . Name , 

—  or  more  crudely  by  a  sinple  (FIFO)  stack  or  (FILD)  queue. 


end  Insert_Narned_Ob j  ect_ACL_Record ; 


procedure  Delete_Named_Ob j  ect_ACLJRecord 

(  Name_of_Object  :  in  BcisicjrcB_Types_Package . 

Nane_of_Ob  j  ect_Type  )  is  —  see  2-4.1 


begin  —  Delete_Named_Ob j  ect_ACL_Record 


—  Sequence  through  the  Named_Ob j  ect_ACL  using  the  typical 

—  list  manipulation  operations  to  locate,  scrub,  and  delete 

—  the  indicated  NamedjOb  j  ect_ACL_Record . 


end  Delete_Named_0b j  ect_ACL_Record ; 


end  NamedjOb  j  ects_Access_Control_Li  st_Manager_Package ; 
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Global  variables  are  a  convenient  means  of  passing  data  between  different 
parts  of  a  system.  "Global  variables"  may  be  implemented  in  Ada  in  a 
package  specification  or  a  subprogram  specification.  The  primary  advantage 
of  using  globed  variables  is  that  sane  efficiency  in  data  transfer  within 
the  program  is  typically  introduced.  This  advantage  is  almost  always  offset 
by  the  problems  caused  by  using  global  variables. 


Guidelines: 

1.  The  vise  of  global  variables  should  be  avoided  because  they  cause 
difficulty  in  tracing  accesses  of  and  modifications  to  the  variables. 

2.  Security  aspects  of  proposed  global  variables  should  be  addressed  as 
early  as  possible  in  the  development  of  a  TCB  system,  preferably  in  its 
requirement  specifications. 

3.  Security  aspects  of  all  global  variables  should  be  reviewed  during 
preliminary  and  detailed  design  reviews  and  code  walkthroughs. 


2  -  7.3  Package  Bodies 

No  additional  Ada-specific  impact  on  TCBs 


2  -  7.4  Private  Type  and  Deferred  Constant  Declarations 

Refer  to  the  discussions  of  data  abstraction  and  information  ading  in 
Section  2-7,  Packages. 

2  -  7.4.1  Private  Types 

For  the  discussion  of  the  use  of  private  types  in  packages,  refer  to  Section 
2-7. 


2  -  7.4.2  Operations  of  a  Private  Type 

Exanple:  The  abstract  data  type,  Key_Type,  is  created  with  the  use  of 

the  package  Key_Manager_Package  and  its  private  type,  KeyJType. 
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package  Key_Manager_Package  is 
type  Keyjiype  is  private; 

NullJKey  ;  constant  Keyjiype; 
procedure  Get_Key  (  K  ;  out  Key_Type  )  ; 
function  (  X,  Y  :  Keyjiype  )  return  BOOIEAN; 

function  "+"  (  X,  Y  :  Keyjiype  )  return  Keyjiype; 

private 

type  Keyjiype  is  new  NATURAL; 

Null_Key  ;  constant  Keyjiype  :=  0; 
end  Key_Manager_Package ; 


package  body  Key_Manager_Package  is 

LastJKey  ;  Keyjiype  :=  0; 

procedure  Get_Key  (  K  :  cut  Keyjiype  )  is 
begin 

Last_Key  ;=  Last_Key  +  1; 

K  Last_Key; 
end  GetJKey; 

function  ”<"  (  X,  Y  :  Keyjiype  )  return  BOOIEAN  .is 
begin 

return  NATURAL  (  X  )  <  NATURAL  (  Y  ) ; 
end  "<”; 

function  (  X,  Y  :  Keyjiype  )  return  Keyjiype  is 
begin 

return  Keyjiype  (  NATURAL  (  X  )  +  NATURAL  (  Y  )  )  ; 
end  "+"; 

end  Key_Manager_Package; 


For  additional  discussion  refer  to  section  2-7. 


2  ~  7,4.3  Deferred  Constants 

No  additional  Ada-specific  inpact  on  TCBs 
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2  -  7.4.4  Limited  Types 

No  additional  Ada-specific  inpact  on  TCBs 

2  -  7.5  Example  of  a  Table  Management  Package 
No  additional  Ada-specific  impact  on  TCBs 

2  -  7.6  Example  of  a  Text  Handling  Package 
No  additional  Ada-specific  impact  on  TCBs 
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2  ~  8.  Visibility  Rules  \ 

This  chapter  of  the  LPW  establishes  rules  for  determining  the  visibility  of  « 
names  and  identifiers  in  the  Ada  program  text.  For  the  most  part,  such 
rules  ate  applicable  at  the  syntactic  and  semantic  phases  of  the  analysis  of  \ 
the  Ada  program  text.  The  two  sections  of  primary  concern  to  software  \ 
development  of  TCBs  are  Use  Clauses  (Section  2  -  8.4)  and  Renaming 
Declarations  (Section  2  ~  8.5).  \ 


2  -  8.1  Declarative  Region 

No  Ada-specific  impact  on  TCBs 


2  -  8.2  Scope  of  Declarations 

No  Ada-specific  inpact  on  TCBs 


2  -  8.3  Visibility  I 

Guidelines:  | 

1.  Avoid  using  global  variables  to  minimize  side  effects,  but  when  they  | 
must  be  used,  restrict  the  visibility  of  global  data  through  the 
scoping  mechanism  [AS05  1987] .  i 


2. 


2  -  8.4 


Avoid  the  nesting  of  subprogram  declarations,  so  as  to  eliminate  the 
potential  for  the  usage  of  global  data  other  than  that  defined  in  the 
main  program  [ASQS  1987]. 


3 

'i 


Use  Clauses 


3 


Ada's  "use  clause  achieves  direct  visibility  of  declarations  that  appear  in 
the  visible  parts  of  named  packages."  The  use  of  the  use  clause  makes 
identifying  the  origin  of  an  invoked  subprogram  difficult.  The  inpact  on 
testing  is  that  the  specification  and  definition  of  the  invoked  subprogram 
are  not  accessible  to  a  tester.  Also,  a  similar  effect,  which  is  equally 
adverse,  occurs  in  maintenance  when  it  is  difficult  to  identify  the  origin 
of  the  invoked  subprogram. 

Guideline: 

1.  Avoid  using  use  clauses  in  Ada  TCB  system  implementation. 
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2  -  8.5  Renaming  Declarations 

Ada's  "renaming  declaration  declares  another  name  for  an  entity."  The  use 
of  renaming  makes  identifying  the  origin  of  an  invoked  subprogram  difficult. 
The  impact  on  testing  is  that  the  specification  and  definition  of  the 
invoked  subprogram  are  not  accessible  to  a  tester.  Also,  a  similar  effect, 
which  is  equally  adverse,  occurs  in  maintenance  when  it  is  difficult  to 
identify  the  origin  of  the  invoked  subprogram. 


Guideline: 

1.  Avoid  using  renaming  declarations. 

2.  Limit  the  redefinition  of  operators.  At  least  limit  the  scope  in  which 
an  operator  is  redefined  [ASOS  1987]. 

2  -  8.6  The  Package  Standard 

No  Ada-specific  impact  on  TCBs 

2  -  8.7  The  context  of  Overload  Resolution 
No  Ada-specific  impact  on  TCBs 
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2-9.  Taste 

This  chapter  of  the  LRM  discusses  the  concurrent  programrtiing  aspects  of  the 
Ada  language.  Concurrent  programming  with  tasking  is  discussed  in  this 
section.  The  discussion  on  system  timing  from  package  CALENDAR  is  located 
in  Delay  Statements,  Duraticn,  and  Time,  (Section  2  -  9.6) .  Also  of  interest 
are  Sections  2  -  9.1  Task  Specifications  and  Task  Bodies,  2  -  9.9  Task  and 
Entry  Attributes,  and  2  -  9.11  Shared  Variables. 

In  contrast  to  other  languages,  Ada  incorporates  its  concurrent  programming 
mechanism,  tasking,  as  an  integral  part  of  its  definition.  Concurrent 
processes,  in  particular  taste,  are  processes  that  may  execute  in  pemliei 
on  multiple  processors  or  independently  scheduled  processes  on  a  u'u.gie 
processor.  That  is,  they  involve  the  simultaneous,  or  timeshared,  ertxwui.cn 
of  processes.  Tasks  may  .interact  with  each  other,  and  one  task  may  suspend 
execution  pending  receipt  of  information  from  another  task  or  the  occurrence 
of  an  external  event.  Despite  the  problems  associated  with  concurrent 
programming  and  Ada's  tasking,  it  is  a  useful  mechanism  that  likely  is 
required  for  the  ef fectiv =  implementation  of  a  TCB  system.  Thus,  Ada's 
tasking  can  promote  an  Ada  TCB  system's  design,  implementation,  and 
maintenance. 

Guidelines: 

1.  Minimize  the  use  of  tasking  [ASOS  1987] . 

2.  Manage  communication  between  taste  in  a  TCB  system  with  discretionary 
access  controls  (e.g. ,  access  control  lists)  and/or  mandatory  access 
controls  (e.g. ,  sensitivity  labels) ,  so  as  to  prevent  the  introduction 
of  covert  channels.  Communications  between  taste  (e.g. ,  rendezvous) 
should  be  logged  in  the  audit  trail. 

3.  Tasking  implementations  shew 'Id  avoid  using  access  types  (for  dynamic 
storage)  and  global  and,  shared  variables. 

4.  Management  of  intertask  communications  should  be  addressed  as  early  as 
possible  in  the  development  of  a  TCB  system,  preferably  in  its 
requirement  specifications. 

5.  Implementation  of  these  intertask  communications  should  be  monitored 
during  the  TCB  system's  preliminary  and  detailed  design  reviews  and 
code  walkthroughs. 
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2-9.1  Task  Specifications  and  Task  Bodies 

Hie  compilation  of  task  specifications  offers  the  same  benefits  as  the 
compilation  of  package  specifications  which  were  discussed  in  Section  2- 
7.2. 


2  -  9.2  Task  Types  and  Task  Objects 

Management  of  intertask  communications  is  a  very  important  aspect  of  the  use 
of  tasks.  The  use  of  semaphores  for  this  purpose  is  presented  in  the 
following  example. 

Example:  This  example  illustrates  trusted  generalized  mechanisms  to 

control  and  regulate  intertask  communications  with  semaphores. 

with  Mandatory_Access_Control JTypes_Package ; 
with  Mandatory_Access_Control_Manager_Package  ; 
with  AuditJirail_Manager_Package ; 
generic 

Max_Nuniber_ofjrasks_Allcwed  :  in  NATURAL  :=  1; 

package  GenericjCounting_Semaphore_Manager_Package  is 

task  type  Count  ing_SemaphoreJTaskJiype  is 
entry  Allcw_Task_to_Pass  ( 

other_Task_MAC_Record  :  in 
Mandatory_Access_Control_Types_Package . 

MAC_Record_Type  ) ;  —  see  3  -  3.1.3 

entry  Release_Task  ( 

Other_Task_MAC_Record  :  in 
Mandatory_Access_Control_Types_Package . 

MAC_Record_Type  );  —  see  3  -  3.1.3 

end  Ccunting_Semaphore_Task_Type; 


—  see  3  -  3.1.3 

—  see  3  -  3.1.3 

—  see  3  -  3.2.3 


end  Generic_Counting_Semaphore_Manager_Package; 
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package  body  Generic_Counting_Semaphore_Manager_Package  is 
task  tody  Counting_Seraphore_Task_Type  is 

Number_of_Tasks  :  INTEGER  :=  Max_Number_of_Tasks_Al  lowed ; 
Iocal_MAC_Record  : 

Mandatory_Aa=ess_Control  Jiypes_Package .  —  see  3  -  3.1.3 

MAC_Record_Type  ? 

r  ,  % 

Other_Task_MAC_Record  : 

Mar^tory_Access_Control_Types_Package .  —  see  3  -  3.1.3 

MAC_Record__Type ; 


begin  —  Countir^_Seai^phore_Task_Type 
loop 
select 

when  Number jof_Tasks  >  0  => 
accept  Allcw_Task_to_Pass  ( 

Other_Task_MAC_Record  :  in 

Jtypes JPackage . 

MAC_Record_Type  )  do  —  see  3  -  3.1.3 

if  Mandatory_Access_Control_Manager_Package . 

Sens  it  ivity_Labels_Match  —  see  3  -  3.1.3 

(  Iocal_MACJRecord.  Sensitivity_Label, 
Otiier_Task_MAC_Record . 

Sensitivity_Label  )  then 

Audit_Trail_Manager_Package.  —  see  3  -  3.2.3 

Log_Sub j  ects_Access_to_Ob j  ect_in_Audit_Trail  ( 
lDcal_MACJRecord,  Other_Task_MAC_Record  )  ? 

i  !umber_of_Tasks  :=  Number_of_Tasks  -  1; 
end  if; 

end  Allw_Task_to_Pass; 


or 

when  Number_of_Tasks  <  Max_Nuniber_of_Tasks_Allowed 
=>  accept  Release_Task  ( 

Ofcher_Task_MAC_Record  :  in 

rjcu  joa  uOj.  y  iu-  x  y  ^c^^irciCKciy  c:  • 

MAC_Record_Type  )  do  —  see  3  -  3.1.3 
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if  Mandatory_Access_Control_Manager_Package. 

Sensitivity_Labels_Match  —  see  3  -  3.1.3 
{  Local_MAC_Record .  SensitivityJLabel , 

Other _Task_MAC_Reoord . 

Sens  itivity_Label  )  then 

Audit_Trail_Manager_Package .  —  see  3  -  3.2.3 

Log_Sub j  ects_Access_tojDb j  ect_in_Audit_Trail  ( 
Local_MAC_Record ,  ~Other JTask_MAC_Reoord  ) ; 

Number_of_Tasks  :=  Number_of_Tasks  +  1; 
end  if; 

end  Release_Task; 
end  select; 
end  loop; 

end  Counting_SemphoreJTask_Type ; 


end  Generic_Counting_Senv3phore_Mcinager_Package ; 


2  -  9.3  Task  Execution  -  Task  Activation 

For  additional  discussion  of  tasking  refer  to  Section  2-9. 

Guideline: 

1.  Initialize  all  object  declarations  in  task  bodies.  mis  includes 
components  of  record  types. 


2  -  9.4  Task  Dependence  -  Termination  of  Tasks 

For  additional  discussion  of  tasking  refer  to  Section  2-9. 

Guideline: 

1.  Scrub  all  objects  declared  in  a  task  before  terminating  the  task. 


2  -  9.5  Entries,  Entry  Calls,  and  Accept  Statements 
Guideline: 

1.  Ensure  that  entry  calls  and  their  corresponding  accept  statements  are 
monitored  by  checking  the  sensitivity  labels  associated  with  the 
respective  tasks  involved  in  a  given  rendezvous.  Also,  the  rendezvous 
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should  be  logged  in  the  audit  trail.  For  additional  tasking  guidelines 
refer  to  Section  2  -  9.0.  Examples  illustrating  this  guideline  are  in 
Sections  2-9.2  and  2  -  9.12. 


2  -  9.6  Delay  Statements ,  Duration,  and  Time 

Ada  provides  access  to  system  timing  through  the  package  CALENDAR.  Only 
system  timing  is  available  from  package  CALENDAR.  To  get  timing  from  an 
external  clock  a  new  package  must  be  developed,  probably  with  representation 
clauses  (more  fully  detailed  in  Chapter  13) ,  which  introduce  their  own 
complications. 

Guidelines: 

1.  Use  of  Ada's  package  CAIENDAR  should  be  minimized  in  Ada  TCB  system 
implementation ;  it  will  probably  be  required  for  time  stairping. 

2.  Security  aspects  of  using  package  CAIENDAR  should  be  addressed  as  early 
as  possible  in  the  development  of  a  TCB  system,  preferably  in  its 
requirement  specifications .  In  particular,  account  for  the  possible 
failure  of  the  system  timing  available  from  package  CAIENDAR  to 
correspond  precisely  to  the  system  clock. 

3.  Security  aspects  of  using  package  CAIENDAR  should  be  monitored  during 
preliminary  and  detailed  design  reviews  and  code  walkthroughs. 


2  -  9.7  Select  Statements 
2  -  9.7.1  Selective  Waits 
Guideline: 

1.  Avoid  the  use  of  selective  waits:  they  introduce  indeterminary.  Ihe 
introduction  of  indeterminacy,  especially  with  selective  waits,  should 
be  monitored  during  preliminary  and  detailed  design  reviews  and  code 
walkthroughs. 


2  -  9.7.2  Conditional  Entry  Calls 

No  additional  Ada-specific  impact  on  TGBs 


2  -  9.7.3  Timed  Entry  Calls 

No  additional  Ada-specific  impact  on  TCBs 
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2  -  9.8  Priorities 

No  additional  Ada -specific  impact  on  TCBs 


2  -  9.9  Thsk  and  Entry  Attributes 

.  Tasks  anr'  entries  have  three  attributes  as  specified  in  the  LRM: 
T1 CALLABLE,  T’TERMINATED,  and  E' COUNT.  The  use  of  these  dynamic  attributes 
enables  the  passing  of  information  in  a  manner  which  is  much  more  difficult 
to  keep  track  of  than  the  normal  manner  of  parameter  passing. 

Guideline: 

1.  Avoid  using  task  and  entry  attributes.  If  used,  the  use  should  be 
monitored  during  preliminary  and  detailed  design  reviews  and  code 
walkthroughs. 


2  -  9.10  Abort  Statements 

■  For  additional  discussion  of  tasking  refer  to  Section  2-9. 
Guideline: 

1.  Scrub  all  objects  declared  in  a  task  before  aborting  the  task. 


2-9.11  Shared  Variables 

Shared  variables  are  the  major  construct  in  tasking  that  will  Liave  to  be 

restricted  (although  perhaps  simulated  through  use  of  other  constructs  using 

synchronization)  in  the  software  development  of  TCBs. 

Guidelines: 

1.  Avoid  using  shared  variables  because  they  cause  difficulty  in  tracing 
accesses  of  and  modifications  to  the  variables. 

2.  Security  aspects  of  proposed  shared  variables  should  be  addressed  as 
early  as  possible  in  the  development  of  a  TCB  system,  preferably  in  its 
requirement  specifications. 

3.  Security  aspects  of  all  shared  variables  should  ue  reviewed  during 
preliminary  and  detailed  design  reviews  and  code  walkthroughs. 
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2-9.12  Example  of  Tasking 

Example:  This  example  illustrates  trusted  generalized  mechanisms  to 

control  and  regulate  intertask  ccrraunications  with  mailboxes. 

with  Mandatory_Access_Control_Types_Package ;  —  see  3  -  3.1.3 

generic 


type  Message_Type  is  private; 
Max_Number_of_Messages  :  in  NATURAL  :=  24; 


package  Generic_Mailbox_Manager_Package  is 


procedure  Send 


(  Message  :  in  Message__Type; 

Local_MAC_Record  :  in 

Mandatory_AccessjControl_Types_Package . 

MAC_Record_Type  );  —  see  3  -  3.1.3 


procedure  Receive  (  Message  :  out  Message_Type  ; 

Iocal_MAC_Record  :  in 

Mandatory_Acx^ss_Control_Types_Package . 

MAC_Record_Type  );  ~  —  see  3  -  3.1.3 

end  Generic_Mailbox_Manager_Package; 


with  Mandatory_Access_Control_Manager_Package;  —  see  3  -  3.1.3 
with  Audit_Trail_Manager_Package ;  —  see  3  -  3.2.3 
package  body  Generic_Mailbox_Manager_Package  is 


task  Manager _Task  is 

entry  Deposit  (  Message  :  in  Message_Type; 

Other _Task_MAC_Record  :  in 
Mandatory_Access_Control_Types_Package . 
MAC_Record_iype  ) ;  —  see  3  -  3.1.3 


entry  Remove 


(  Message-  :  out  MessageJType ; 

Other_Task_MAC_Record  :  in 
Mandatory_Access_Control_Types_Package . 


end  ManagerJTask; 


rn  rv»^s  \  • 


O  —  *2  1  *3 
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procedure  Send  (  Message  :  in  Message_Type  ; 

Local_MAC_Record  :  in 
Mandatory_Acoess_ContxolJTypesJPackage. 

MAC_Record_Type  )  is  —  see  3  -  3.1.3 

begin 

Manager_Task.  Deposit  (  Message,  Iocal_MACJReoord  ) ; 
end  Send; 

procedure  Receive  (  Message  :  out  Message Jiype; 

Local_MACJRecord  :  .in 
Mandatory_Access__Control_Types_l  'dkage. 

MAC_Record_Type  )  is  —  see  3  -  3.1.3 

begin 

Manager_Task.  Remove  (  Message,  Incal_MAC_Record  ) ; 
end  Receive; 


task  body  ManagerJTask  is 

subtype  Mailbc«_Slct_IndexJiype  is  INTEGER  range 
0  . .  (  Max_Nuraber_of ^Messages  -  1  ) ; 

HeadJSlot  ;  Mailbox_Slot_Index_Type  ;=  0; 

Tail_Slot  ;  Mailbox_Slot_Index_Type  :=  0; 

Message  _Number  :  INTEGER  range  0  ..  Max_Number_of_Messages; 

Mailbox  :  array  (  Mailbox_Slot_Index_Type  )  of  Message_Type ; 

Iocal_MACJRec°ni  : 

Mandat ory__Access_Control_'iypes_Package .  —  see  3  -  3.1.3 

MAC_RecordJiype ; 

Other_Task_MAC_Record  ; 

Mandatory Jtocess_ControlJTypes_Package.  —  see  3  -  3.1.3 
MAC_Record _iype ; 

begin 

loop 

select 

when  Message_Number  <  Max_Nuraber_of_Messages  => 

accept  Deposit  (  Message  :  in  MessageJType; 

Other_Task_MAC_Record  :  in 
Mandatory_Access_Control_Types JPackage . 
MACJRecordJiype  )  do 

—  see  3  —  3.1.3 


C-61 


APPENDIX  C 

Mapping  Of  TCB  Relevant  Ada  Constructs  and  Features  To 
The  Reference  Manual  For  The  Ada  Programming  Tangnanp 


if  Mandatory_Access_Control_Manager_Package . 

Sensitivity_Labels_Match  —  see  3  -  3.1.3 

(  Iocal_MAC_Record.  SensitivityJLabel, 
Other_Task_MAC_Record . 

Sens itivity_Iabel  )  then 

Audit_Trail_Manager_Package.  —  see  3  -  3.2.3 

Lcg_Sub j  ects_Acx»ss_to_Ob j  ect_in_Audit_Trail  ( 
Iocal_MAC_Record ,  Other JTask_MAC_Reoord  ) ; 


Mailbox  (  Head_Slot  )  :=  Message; 

Head_Slot  ;=  (  Head_Slot  +  1  )  mod 
Max_Nuntoer_of_Messages ; 

Message_Number  :=  Message_Number  +  1; 
end  if; 
end  Deposit; 


or 


when  MessageJNuraber  >  0  => 

aooept  Remove  (  Message  : ,  out  MessageJType; 

Other_Task_MAC_Record  :  in 
Mandatory_Access_Ctontrol_Types_Package . 
MAC_Record_Type  )  do 

—  see  3  -  3.1.3 

if  Mandatory_Access_Control_Manager_Package. 

Sensitivity_Labels_Match  —  see  3  -  3.1.3 

(  Local_MAC_Recoru.  Sensitivity_Iabel , 
Other_Task_MAC_Record . 

Sensitivity_Label  )  then 


Audit_Trail_Manager_Package.  —  see  3  -  3.2.3 
Log_Sub j  ec±s_Access_to_Ob  j  ecfc_in_Audit_Trail  ( 
Local_MAC_Rec°rd ,  Other_Task_MAC_Record  ) ; 

Message  ;=  Mailbox  (  Head_Slot  ) ; 

Tail_Slot  :=  (  Tail_Slot  +  1  )  mod 

ijOa  wi 
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Message_Number  :=  Message_Number  -  1; 
end  if; 
end  Remove; 
end  select; 
end  loop; 
end  ManagerJTask; 

end  Generic_Mailbox_Manager_Package; 
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2  -  10.  Program  Structure  and  Compilation  Issues 

This  chapter  of  the  LRM  describes  the  units  of  compilation,  attends  to  the 
ordering  requirements  for  program  libraries,  and  touches  briefly  on  the 
results  of  optimizations.  Reusable  code  is  discussed  in  Section  2  -  10.4 
Ohe  Program  Library. 


2  -  10.1  Ccnpilation  Units  -  Library  Units 
Guideline: 

1.  Use  libraries  to  greatly  facilitate  good  configuration  management  [ASQS 
1987]. 


2  -  10.1.1  Context  Clauses  -  With  Clauses 
No  Ada-specific  inpact  on  TCBs 


2  -  10.1.2  Examples  of  Oapilati.cn  Units 
No  Ada-specific  inpact  on  TCBs 


2  -  10.2  Subunits  of  Compilation  Units 
2  -  10.2.1  Examples  of  Subunits 
No  Ada-specific  inpact  on  TCBs 


2  -  10.3  Order  of  Compilation 

No  Ada-specific  impact  on  TCBs 


2  -  10.4  The  Program  Library 

Hie  program  library  should  contain  reusable  code.  The  implementation  of  an 
Ada  TCB  system  can  be  aided  with  the  reuse  of  evaluated  code  that  has  been 
demonstrated  to  sufficiently  satisfy  the  security  class  of  the  given  TCB. 
Ada's  generic  units  are  helpful  in  creating  reusable  code.  "Generics 
provide  a  powerful  means  by  which  a  program  may  be  'factorized'  in  order  to 
shorten  code,  and  reduce  incidence  of  errors,  by  avoiding  redefining  items 
which  appear  in  several  places  in  the  program"  [Nissen  and  Wallis  1984, 
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p.  181] .  When  code  is  reused,  the  number  of  errors  in  the  code  is  reduced,  \ 
because  errors  in  such  code  are  fixed  when  they  are  identified.  Additional  ] 
time  and  effort  is  required  during  the  design  phase  of  developing  reusable  I 
code  for  a  TCB  system.  The  additional  time  and  effort  will  pay  for  itself  ; 
When  the  resulting  reusable  code  is  used  in  multiple  instances  in  the  j 
current  TCB  and  future  ICBs.  Thus,  the  reuse  of  evaluated  code  is  a  sound 
software  engineering  technique  that  can  promote  the  efficient  production  of  ; 
an  Ada  TCB  system's  design,  implementation,  and  maintenance.  ; 

3 

Guidelines:  \ 

1.  Use  existing  evaluated  reusable  software  conponents  as  much  as  possible  > 

to  create  modular  software  to  promote  efficient  Ada-TCB  system's  ; 
design,  implementation,  and  maintenance.  That  is,  reuse  the  code 
and/or  the  design  that  has  been  demonstrated  to  sufficiently  satisfy  f 
the  security  class  of  the  given  Ada  TCB  system.  I 

2.  Create,  manage,  and  \ase  libraries  of  evaluated  reusable  software 
components.  Libraries  of  evaluated  reusable  Ada  source  code  should  be 
established  and  managed  by  the  security  administrator,  who  supervises  i 
access  to  and  use  of  the  libraries.  An  example  of  such  a  library  is 
discussed  in  the  paper  "A  Secure  SOS  Software  Library”  [Hadley,  et.  al. 
1987] . 

3.  Ada's  generic  units  should  be  taken  full  advantage  of  when  creating 
this  reusable  code,  as  exemplified  in  Booch's  Software  Components  with 
Ada  [1987A] . 

4.  Monitor  the  implementation  of  these  libraries  of  evaluated  reusable 
software  components  during  preliminary  and  detailed  design  review's  and 
code  walkthroughs. 

5.  Errors  found  in  code  taken  from  libraries  of  evaluated  reusable 
software  components  should  be  reported  to  the  library  manager. 


10.5  Elaboration  of  Library  Units 
No  Ada-specific  impact  on  TCBs 


10.6  Program  Optimization 
No  Ada-specific  impact  on  TCBs 
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2  -  11.  Exceptions 

This  chapter  of  the  IPM  defines  the  exception  constructs,  and  mechanisms, 
and  rules  of  handling  exceptions  within  programs.  A  general  discussion  of 
exceptions  is  located  in  this  section.  Other  sections  of  interest  are  2- 
11.4  Exception  Handling,  2  -  21.4.1  Exceptions  Raised  During  the  Exception 
of  Stataaaenfcs,  and  2  -  11.7  Suppressing  Checks. 

Ada  handles  program  execution  errors  or  other  exceptional  situations  with 
its  exception  handling  mechanism.  An  exception  may  be-  used  to  alter  control 
of  program  execution  (e.g.,  handling  the  exception  outside  a  subprogram  or  a 
task  where  the  exception  was  raised) . 

Using  pragma  SUPPRESS  prevents  the  raising  of  exceptions  for  selected 
checks,  which  can  serve  to  monitor  the  proper  execution  of  the  program 
during  runtime.  Ada  code  generated  when  using  pragma  SUPPRESS  cannot  be 
trusted  to  work  as  expected  because  Ada  compilers  currently  are  not 
validated  when  pragma  SUPPRESS  is  used. 

Guictelines: 

1.  Exception  handling  must  be  managed  in  a  TCB  system.  Handling  an 
exception  between  the  point  at  which  the  exception  is  raised  and  the 
place  where  it  is  handled  (especially  if  they  are  in  separate  modules)  ‘ 
must  be  enforced  in  a  TCB  system  with  discretionary  access  controls 
(e.g.,  access  control  lists)  and/or  mandatory  access  controls  (e.g., 
sensitivity  labels) .  Each  exception  should  be  labeled  so  that  the 
initiator  of  the  exception  is  kncwn  by  its  exception  handler. 

2.  Only  define  exception  to  handle  events  that  occur  infrequently  [ASOS 
1987]. 

3.  Handle  frequent  occurrences  of  bad  data  by  direct  coding  in  subprograms 
[ASOS  1987], 

4.  Security  aspects  of  the  various  exception  handling  operations  should  be 
addressed  as  early  as  possible  in  the  development  of  a  TCB  system, 
preferably  in  its  requirement  specifications. 

5.  These  operations  should  be  stipulated  by  the  TCB  system  requirements 
specification  or  design  documents. 

6.  Implementation  of  these  operations  should  be  managed  during  preliminary 
and  detailed  design  reviews  and  code  walkthroughs. 

7.  Avoid  using  pragma  SUPPRESS. 
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Exanple:  mis  example  illustrates  trusted  exception  handling  that  allows 
program  execution  to  continue  in  a  trusted  manner. 

generic 


type  Namejiype  is  private; 
type  ACL_Record_Type  is  private; 


package  Generic_Access_Control_List_Manager_Package  is 


procedure  Get_ACL_Record 

(  Name  :  in  Namejiype; 

ACL_Record  :  out  ACL_Record_Type  ) ; 

procedure  Insert_ACLJRecord 

(  ACL_Record  :~in  ACOJRecordJiype  ) ; 

procedure  Delete_ACL_Record 
(  Name  :  in  Namejiype  ) ; 


Overflcw_Access_Control_List  :  exception; 
Acxessjdontrol_List_is_Null  ;  exception; 

private 


end  Generic_Access_Control_List_Manager_Package; 


with  Access j3ontrol_ListJiypes_Package; 

with  Mandatory_Access_ControlJiypes_Package;  —  see  3  -  3.1.3 
With  ACCESS  Control  Marjagov*  PSCJC2^3  *  —  coo  3  3-1-3 
with  Audit JTrail_Manager_Package ;  —  see  3  -  3.2.3 
package  body  Generic_Access_Control_List_Mimager_Package  is 


067 


APPENDIX  C 

Mapping  Of  TCB  Relevant  Ada  Constructs  and  Features  To 
The  Reference  Manual  F'or  The  Ada  Programming  Language 


—  The  user  can  gain  only  indirect  access  to  instantiated 

—  access  control  list  through  the  subprograms  declared  in  the 

—  package  specification.  Thus  the  access  control  list  data 

—  structure  is  hidden  from  the  user  cf  this  package.  The 

—  typical  list  manipulation  operations  (  e.g. ,  as  illustrated 

—  by  Booch  1987A  and  Feldman  1985  )  are  only  provided  in  the 

—  package  body. 


Exception_Raiser_Record : 

Meindatory_Access_Control_Types_Package .  —  see  3  -  3.1.3 

MAC_Record_Type ;  —  Initialize  Exception_Raiser_Record . 


Exception_Handler_Record  : 

Mandatory_Access_Control_Types_Package .  —  see  3  -  3.1.3 

MAC_Record_Type ;  —  Initialize  Except ion_Handler_Record . 


Typical  list  manipulation  operations 


procedure  Get_ACL_Record 

(  Name  :  in  Name_Type; 

ACLJRecord  :  cut  ACL_Record_Type  )  is 


Exception_Name  : 

Mandatory_Access_Control_Types_Package.  —  see  3  -  3.1.3 
Exception_Name_Type  := 
Mandatory_Access_Control_Types_Pac)'sge . 

Others_String; 


begin  —  Get_ACL_Record 


—  Sequence  through  the  access  control  list  data  structure 

—  using  the  typical  list  manipulation  operations  to  locate 

—  and  get  the  indicated  access  control  list  record. 
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exception 


When  others  => 

Audit  Tra il_Manager_Package .  —  see  3  -  3.2.3 

]^”£xc»ptic«_in_Aixiitjrrail  ( 

ExoeptionJName , 

Exception_Raiser_Record , 

Exception_Handler_Record  ) ; 

end  Get_ACL_Record; 


procedure  Insert_ACL_Record 

(  ACL_Record  :  in  ACL_Record_Type  )  is 


Exception_Name  : 

Mandatory_Aocess_Control_Types_Package .  —  see  3  -  3.1.3 

ExceptionJNameJiype  := 
Mandatory_Access_ControJ._Types_Package . 

Others_Str ing ; 


begin  —  Insert_ACL_Record 


—  Sequence  through  the  access  control  list  data  structure 

—  using  the  typical  list  manipulation  operations  to  locate 

—  the  appropriate  place  to  insert  the  indicated 

—  access  control  list  record.  This  location  is 

—  determined  by  a  predefined  mechanism,  e.g.,  alphabetizing  by 

—  the  "name"  of  the  access  control  list  record,  or  more 

—  crudely  by  a  simple  (FIFO)  stack  or  (FILO)  queue. 


—  Check  for  the  exception  Overflcw_Access_Control_List. 

—  If  the  exception  is  to  be  raised,  then  set  the 

—  Exception_Name  and  Exception_Raiser_Record. 
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exception 


when  Overflcw_Access_Control_List  => 

Aixiit_Trail_Manager_Package .  —  see  3  -  3.2.3 

Log_Except  ion_in_Aiid  i.t_Trail  ( 

Except ion_Name , 

Exception_Raiser_Record, 

Exoepticn_Harriler_Record  ) ; 

•  •  • 

when  others  => 

Audit JTrail_Manager_Package.  —  see  3  -  3.2.3 

Ing_Exceptionjin_Aui  itJTrail  ( 

Exception_Name , 

Except  ion  JRciiser_Reoord , 

Exoeption3jandler_Reccrd  ) ; 

end  Insert_ACL_Record; 


procedure  Delete_ACL_Record  (  Name  :  in  NameJType  )  is 


Exception_Name  : 

Mandatory_Access_Control_TVpes_Package.  —  see  3  -  3.1.3 
Except ion_Nare_Type  := 
Mandatory_Access_Control_Types_Pac}3ge . 

Others_String ; 


begin  —  Delete_ACL_Record 


—  Sequence  through  the  access  control  list  data  structure 

—  using  the  typical  list  manipulation  operations  to 

—  locate,  scrub,  and  delete  the  indicated 

—  access  control  list  record. 
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—  Check  for  the  exception  Acx3essJDontrol_List_isJ^ull. 

—  If  the  exception  is  to  be  raised,  then  set  the 

—  Exception_Name  and  Exception JF&iserJRecord . 


exception 


when  Acc^ss_Control_List_is_Null  => 

Audit_Trail_Manager_Package.  —  see  3  -  3.2.3 

Ijcg_Exception_in_Audit_Trail  ( 

Except ion_Name , 

Exception_Raiser_Record , 

Exception_Handler_Record  ) ; 


when  others  => 

Audit_Trail_Manager_Package .  —  see  3  -  3.2.3 

Icg_Exception_in_AuditJPrail  ( 

Except  ion_Name , 

Exception_Raiser_Record , 

ExceptionJHandlerJRecord  ) ; 

end  Delete_ACL_Record; 


end  Generic_Access_Control_List_Manager_Package; 


2  -  11.1  Exception  Declarations 

No  additional  Ada-specific  inpact  on  TCBs 

^  *1  *1  M  TT— jn  — 

c  “  xkujujlc; i.& 

No  additional  Ada-specific  inpact  on  TCBs 
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2  -  11.3  Raise  Statements 

No  additional  Ada -specific  impact  on  TCBs 


2  -  11.4  Exception  Handling 

Exceptions  in  Ada  are  handled  by  the  innermost  execution  frame  or  accept 
statement  enclosing  the  statement  that  caused  the  exception.  (Exceptions 
within  accept  statements  are  discussed  in  Section  2  -  11.5.)  Because  the 
Ada  mechanism  for  propagating  exceptions  is  dynamic,  it  deserves  special 
attention  as  discussed  in  Section  2-11. 

Guidelines: 

1.  Implement  exceptions  in  a  well-disciplined  manner.  Because  of  Ada's 
possible  dynamic  binding  of  exceptions  to  handlers,  place  restrictions 
on  the  implementation  of  exception  handling  to  ensure  that  all  control 
paths  can  be  determined  statically.  At  the  TCB  boundary,  all 
exceptions  rnufrt  be  handled  or  explicitly  propagated.  Similarly, 
implicit  propagation  of  exceptions  is  disallowed  within  subprograms. 
An  others  clauses  is  placed  in  each  subprogram  to  ensure  that  ary 
exception  signaled  within  its  body  will  be  handled.  These  restrictions 
will  make  control  flow  more  predictable  [ASQS  1987) . 

2.  When  a  subprogram's  execution  is  aborted  because  of  an  exception,  the 
values  out  and  in  out  parameters  of  array  and  record  types  is  dependent 
on  the  parameter  passing  mechanism  employed  by  the  compiler.  To  foster 
a  consistent  approach,  ASOS  requires  that  the  handler  of  an  exception 
assume  nothing  about  the  values  of  the  parameters  [ASOS  1987). 

3.  Because  the  effects  of  Ada  exceptions  from  predefined  operations  are 
not  well  specified,  handlers  shall  not  assume  anything  about  the  values 
of  result  variables  involved  in  such  predefined  operations  [ASOS  1987). 


2  -  11.4.1  Exceptions  Raised  During  the  Execution  of  Statements 

A  major  difficulty  with  exceptions  in  the  Ada  language  is  the  dynamic  manner 
in  which  exceptions  are  propagated  and  the  resulting  complexity  that  derives 
from  attempting  analysis  during  testing  of  programs.  This  is  a  specific 
example  of  the  general  discussion  in  Section  2-11. 


2  -  11.4.2  Exceptions  Raised  During  the  Elaboration  of  Declarations 
No  additional  Ada-specific  impact  on  TCBs 
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2  -  11.5  Exceptions  Raised  During  Task  Onnamication 

Exceptions  raised  during  task  oorirunication  are  complicated  more  by  the 
difficulty  in  handling  tasking  in  Ada  than  by  the  use  of  exceptions  in 
tasks. 


Guideline: 

1.  Avoid  handling  an  exception  outside  of  the  task  that  raises  the 
exception.  The  use  of  such  exceptions  should  be  iionitored  during 
preliminary  and  detailed  design  reviews  and  code  walkthroughs. 

2  -  11.6  Exceptions  and  Optimization 

No  additional  Ada-specific  impact  on  TCBs 


2  -  11.7  Suppressing  Checks 

Using  pragma  SUPPRESS  prevents  the  raising  of  exceptions  for  selected 
checks,  which  can  serve  to  monitor  the  proper  execution  of  the  program 
during  runtime.  Ada  code  generated  when  using  pragma  SUPPRESS  cannot  be 
trusted  to  work  as  expected  because  Ada  compilers  currently  are  not 
validated  when  pragma  SUPPRESS  is  used. 


Guideline: 

1.  Avoid  using  pragma  SUPPRESS. 
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2  -  12.  Generic  Units 

This  chapter  of  the  LRM  describes  the  structure  and  application  of  generic 
units  within  Ada.  lhe  use  of  generic  constructs  is  one  of  the  more  novel 
innovations  in  the  Ada  language.  Generic  units  should  be  used  in  creating 
reusable  code,  as  was  discussed  in  lhe  Program  Library  (Section  2  -  10.4) . 


Guideline: 

1.  Use  generic  units  to  write  generalized  software  that  will  perform 
.  operations  on  classes  of  data  types  [ASOS  1987].  .  . 


2  -  12.1  Generic  Declarations 

No  Ada-specific  impact  on  TCBs 

2  -  12.1.1  Generic  Format  Objects 
No  Ada-specific  impact  on  TCBs 

2  -  12.1.2  Generic  Formal  Types 

No  Ada-specific  impact  on  TCBs 

2  -  12.1.13  Generic  Formal  Subprog 
No  Ada-specific  impact  on  TCBs 

2  -  12.2  Generic  Bodies 

No  Ada-specific  impact  on  TCBs 


2  -  12.3  Generic  Instantiation 

No  Ada-specific  impact  on  TCBs 


2  -  12.3.1  Matching  Rules  for  Formal  Objects 
No  Ada-specific  impact  on  TCBs 
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2  -  12.3.2  Matching  Rules  for  Formal  Private  Types 
No  Ada-specific  inpact  on  TCBs 

2  -  12.3.3  Matching  Rules  far  Formal  Scalar  Types 
No  Ada-specific  inpact  on  TCBs 

2  -  12.3.4  Matching  Rules  far  Formal  Array  Types 
No  Ada-specific  inpact  on  TCBs 

2  -  12.3.5  Matching  Rules  for  Formal  Access  Types 
No  Ada-specific  inpact  on  TCBs 

2  -  12.3.6  Matching  Rules  far  Formal  Subprograms 

2  -  12.4  Example  of  a  Generic  Package 

Example:  This  example  illustrates  a  generic  package  for  multiple  instances 
of  an  access  control  list,  with  instantiations  of  the  package. 

generic 

type  Namejiype  is  private; 
type  ACL_Record_Type  is  private; 

T 11  •  •  • 

package  Generic_Access_Control_List_Manager_Package  is 

procedure  Get_ACL_Record 

(  Name  :  in  Name_Type; 

ACLJRecord  :  out  ACL_Record_Type  ) ; 


C-75 


APPENDIX  C 

Mapping  Of  TCB  Relevant  Ada  Constructs  and  Features  To 
Hie  Reference  Manual  For  me  Ada  Programming  Language 


procedure  Insert_ACL_Record 

(  ACLJRecord  :  in  ACL_Record_Type  ) ; 

procedure  Delete_ACL_Reoord 
(  Name  :  in  Name_Type  ) ; 


Overflcw_Aooess_Control_List  :  exception; 
Access _Control_List_is_Null  :  exception; 

private 


end  Generic_Access_Control_List_Manager_Package ; 


with  Acx3essjControl_List_TVpes_Package; 

with  Mandatory_AccessjCtontroi_Types_Package;  —  see  3  -  3.1.3 

with  Mandatory_Access_Control Jtanager_Package ;  —  see  3  -  3.1.3 

with  Audit _Trail_Manager_Package;  —  see  3  -  3.2.3 

package  body  Generic_Access_Control_List_Manager_Package  is 

—  me  user  can  gain  only  indirect  access  to  instantiated 

—  access  control  list  through  the  subprograms  declared  in  the 

—  package  specification.  Thus  the  access  control  list  data 

—  structure  is  hidden  from  the  user  of  this  package,  me 

—  typical  list  manipulation  operations  (  e.g. ,  as  illustrated 

—  by  Booch  1987A  and  Feldman  1985  )  are  only  provided  in  the 

—  package  body. 


Typical  list  manipulation  operations 


procedure  Get_ACL_Record 

(  Name  :  in  Name_Type  ? 

ACLJRecord  :  out  ACL_P.ecord_Type  )  is 
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begin  —  Get_ACL_Record 


—  Sequence  through  the  access  control  list  data  structure 

—  using  the  typical  list  manipulation  operations  to  locate 

—  and  get  the  indicated  access  control  list  record. 


end  Get_ACLJRecord; 

procedure  Insert_ACL_Record 

(  ACL_Record  :  in  ACL_Record_Type  )  is 


begin  —  Insert_ACL_Record 


—  Sequence  through  the  access  control  list  data  structure 

—  using  the  typical  list  manipulation  operations  to  locate 

—  the  appropriate  place  to  insert  the  indicated 

—  access  control  list  record.  This  location  is 

—  determined  by  a  predefined  mechanism,  e.g.,  alphabetizing  by 

—  the  "name"  of  the  access  control  list  record,  or  more 

—  crudely  by  a  simple  (FIFO)  stack  or  (FILD)  queue. 


end  Ir^rt_ACL_Record? 


procedure  Delete_ACL_Record  (  Name  :  in  Name_Type  )  is 


begin  —  Delete_ACL_Record 


—  Sequence  through  the  access  control  list  data  structure 

—  using  the  typical  list  manipulation  operations  to  locate, 

—  scrub,  and  delete  the  indicated  access  control  list  record. 
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end  Delete_ACL_Record  ; 


end  Generic_Access_Control_List_Manager_Package; 


—  Instantiations  of  Generic_AooessjOontrol_List_Manager_Package 
package  NamedjOb j  ecfcs_Aa3essjOontrol_List_Manager_Package  is  new 
GerKeric_Acx^ess_Control_List_Manager_Package 
(  NameJIype  =>  BasicJTCB_Types_Package . 

Nair»e_of_Obj  ect_Type , 

ACL_Record_Type  =>  Acc»ss_tontrolJListJI^pes_Package. 

NamedjDb j  ect_Record_Type  ) ; 


package  Naroed_Individuals_Acxcess_Control_List_Manager_Package  is  new 
Generic_7yccess_Control_List_Manager_Package 
(  Name_Type  =>  Basic_TCB_Types_Package. 

Name_of _0b j  ect_Type , 

ACLJRecordJiype  =>  Acxcess_Ctontrol_List_Types_Package . 

Named_Individual_RecordJIVpe  ) ; 


package  Grx»4DS_of_Nared_Individual  s_ACL_Manager_Package  is  new 
Generic_Access_Ctontrol_List_Manager_Package 
(  Name_Type  =>  Basic_TCB_Types_Package . 

Name_of_Ob j ect_Type , 

ACL_Recaord_Type  =>  Acx^ssjOontrol_ListJTypes_Package . 

Gro'jp_of_Mamed_Individuals_Record_Type  )  ; 


C-78 


APPENDIX  C 

Mapping  Of  TCB  Relevant  Ada  Constructs  and  Features  Tc 
Tiie  Reference  Manual  For  The  Ada  Programing  Language 


2-13.  Representation  Clauses  and  Implementation-Dependent  Features 

This  chapter  of  the  IRM  discusses  implementation-specific  matters  at  a  low 
level.  Several  of  the  constructs,  such  as  representation  clauses,  length 
clauses,  enumeration  representation  clauses,  and  address  clauses  are  on  the 
order  of  specific  directives  to  the  ccnpiler  and  would  have  no  noticeable 
effect  on  the  execution  of  the  resulting  program.  Interrupts  are  discussed 
in  Section  2  -  13.5.1.  Machine  code  insertions  (Section  2  -  13.8)  and 
interfaces  to  subprograms  written  in  other  languages  (Section  2  -  13.9)  may 
introduce  complications  in  developing  TCBs.  Also  of  interest  to  the 
development  TCBs  is  unchecked  programing  (Section  2  -  13.10) . 


Guidelines: 

1.  me  use  of  representation  clauses  and  inplementation-dependent  features 
should  be  avoided  in  Ada  TCB  system  implementations. 

2.  Security  aspects  of  using  any  representation  clauses  and 
implementation-dependent  features  should  be  addressed  as  early  as 
possible  in  the  development  of  a  TCB  system,  preferably  in  its 
requirement  specifications. 

3 .  me  use  of  any  representation  clauses  and  inplementation-dependent 
features  should  be  restricted  to  a  minimum  number  of  packages  and 
subprograms  to  assist  in  monitoring  their  use  and  to  aid  in  system 
portability. 


2  -  13.1  Representation  Clauses 

No  additional  Ada-specific  impact  on  TCBs 


2  -  13.2  length  Clauses 

No  additional  Ada-specific  impact  on  TCBs 

2-13.3  Enumeration  Representation  Clauses 
No  additional  Ada-specific  impact  on  TCBs 

2  -  13.4  Record  Representation  Clauses 

No  additional  Ada-specific  impact  on  TCBs 
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2  -  13.5  Address  Clauses 

No  additional  Ada -specific  impact  on  TCBs 


2  -  13.5.1  Interrupts 

Interrupts  provide  asynchronous  means  of  altering  program  execution,  so  that 

an  external  event  can  be  handled  by  the  system.  This  change  in  program 

execution  must  be  managed  and  documented. 

Guidelines: 

1.  Each  interrupt  should  be  labeled  so  that  the  initiator  of  the  interrupt 
is  known  by  its  interrupt  handler.  Interrupts  should  be  managed  with 
discretionary  access  controls  (e.g. ,  access  control  lists)  and/or 
mandatory  access  controls  (e.g. ,  sensitivity  labels) .  Interrupts 
should  be  monitored  by  logging  them  in  the  audit  trail. 

2.  All  interrupts  that  affect  a  TCB  must  be  raised  within  the  TCB  and 
handled  by  the  TCB. 

3.  Security  aspects  of  the  various  interrupt  operations  should  be 
addressed  as  early  as  possible  in  the  development  of  a  TCB  system, 
preferably  in  its  requirement  specifications. 

4 .  Implementation  of  these  interrupt  handling  operations  should  be 
monitored  during  the  TCB  system's  preliminary  and  detailed  design 
reviews  and  code  walkthroughs. 


Example:  This  example  illustrates  trusted  interrupt  handling. 

Note  that  address  clauses  are  not  currently  supported  in  VAX  Ada. 

with  Mandatory_Access_Control_Types_Package;  —  see  3  -  3.1.3 

package  Interrupt_Handler_Package  is 

procedure  Get_Character  (  Char  :  cut  CHARACTER; 

Local_MAC_Record  :  in 
Mandatory_Access_Ccntrol_Types_Package . 
MAC_Pecord_TVpe  ) ;  —  see  3  -  3.1.3 
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procedure  Put_Character  (  Char  :  in  CHARACTER; 

Incal_MACJRecord  :  in 
Mandatory_Access_Ccntrol_Types_Package . 
MAC_Record_Type  ) ;  —  see  3  -  3.1.3 

end  Interrupt_Handl er_Package ; 


with  Mandatory_Aooess_control_Manager_Pac)oage;  —  see  3  -  3.1.3 
with  AixiitJirail_Manager__Package;  —  see  3  -  3.2.3 
package  tody  Interrupt_Handler_Package  is 


task  mterrupt_Input_Handler_Task  is 
pragma  PRIORITY  (  4  ) ; 

—  must  have  at  least  the  priority  of  the  interrupt 

entry  Get_Character_frcm_Irrterri^_Ifput_Addr'3ss 
(  Char  :  out  CHARACTER; 

OtherJDask_MAC_Reoord  :  in 
Mandatory_Ac5ess_Control  _Types_Package . 

MAC_Record_Type  ) ;  —  see  3  -  3.1.3 

entry  Save_Hardware_Buf  fer_Character  ( 
other_Thsk_MAC_Record  :  in 
Mandatory_Access_Control_Types_Package . 

MAC_Record_Type  ) ;  —  see  3  -  3.1.3 

—  assuming  that  SYSTEM.  ADDRESS  is  an  INTEGER  type 
far  Save_Hardware_Buffer_Character  use  at  16#0020#; 

end  mterri^_Irprt_Handler_Task ; 


task  mterrL^_0ul5xrt_Haridler_Task  is 
pragma  PRIORITY  (  4  ) ; 

—  must  have  at  least  the  priority  of  the  interrupt 

V4&W.J  V  VMKAXUVWWi  dU  «WV  A  •*-*-*.  SMMMX  *w»  I>»v4i.  ^ 

Other_Task_MAC_Record  ;  in 
Mandatory_Access_Control_Types_Package . 

MAC_Record_Type  ) ;  —  see  3  -  3.1.3 
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entry  Put_Character_into_InterruptjCXitput_Ad±ress  ( 

Char  :  in  CHARACTER; 

Other_Tas3  :_MAC_Record  :  in 
Mandatory_Aooess_Oontrol_Types_Package . 

MAC_Record_Type  ) ;  —  see  3  -  3.1.3 

—  assuming  chat  SYSTEM.  ADCRESS  is  an  INTEGER  type 

far  DepositjCharacter_into_Hardware_Buffer  use  at  16# 0024#; 

end  Interrupt_Output_Handler_Task ; 


procedure  GetjCharacter  (  Char  :  out  CHARACTER; 

Local_MAC_Recoxd  :  in 

Mandatory_Access__Contuol_Types_Package . 
MAC_Record_Type  )  is 

—  see  3  -  3.1.3 

begin  —  Get_Character 

3nterrupt_Input_Hardler_Tcis}c . 

Get_Qraracter_fratt_3nterrup 
(  Char,  Iocal_MAC_Reoord  ) ; 


end  Get  Character; 


procedure  Put_Character  (  Char  :  in  CHARACTER; 

Iccal_MAC_Record  :  in 

Mandatory_Access_Control_Types_Package . 
MAC_Record_Type  )  is 

—  see  3  -  3.1.3 


begin  —  Put_Character 


Interrupt_Output_Handler_Task. 

Put_Character_into_3nterri^t_Output_Ac  dress 
(  Char,  Local_MAC_Record  ) ; 

end  Put  Character; 


task  body  Interrupt_Input_Handler_Task  is 

h^jSize_of_Internal_Ir^xit_Buffer  ;  constant  POSITIVE 
;=  64; 
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Intemal_Input_Buffer  : 

array  (  1  . .  Max_S  ize_of_Intemal_Input_Buf f er  ) 
of  CHARACTER? 

Input_Buffer_Pointer  :  POSITIVE  :=  1; 

Output_Buffer_Po inter  :  POSITIVE  :*  1; 

BufferjCount  :  INTEGER  :=  1; 

Hardware_Character_Buffer  :  CHARACTER? 

for  Hardware jCharacter_Buffer  use  at  16#0100#; 

Ioced_IrpjtJiask_^C_Record  : 

Mandatory_Acoess_Control_Types_Package.  —  see  3  -  3.1.3 
MAC_Record_Type ; 

Other_Task_MAC_Record  : 

Mandatory_Access jOontrol JTypes_Package .  —  see  3  -  3.1.3 

MAC_Record_Type ? 

begin  —  Internjpt_Irput_Handler_Task 
locp 
select 

when  BufferjCount  >  0  => 

accept  Get_Qiaracter_frcm_Interrupt_lnput_Address 

(  Char  :  out  CHARACTER; 

Other  JTask_MAC_Record  :  in 

Mandatory_Access_Control  JTypes_Package . 
MAC_Record_Type  )  do 

—  see  3  -  3.1.3 


if  Mandatory_Access_Control_Manager_Package. 

Sensitivity_Labels_Matdh  —  see  3  -  3.1.3 

(  Local_]jput JTask_MAC_Record . 

Sens it ivity_Iabel , 

Other JIhsk_MAC_Record. 

SensitivityJLabel  )  then 

Audit JIrail_Manager_Package .  —  see  3  -  3.2.3 

Log_Sub j  ects_Access_to_Ob j  ect_in_Audit__Trail  ( 
Jjocal_Input_Task_MAC_Record , 

Other  JTask_MAC_Record  ) ; 

Char  :=  Internal JEnput_Buffer( 

Output_Buffer_Po inter  ) ; 


C-83 


APPENDIX  C 

Mapping  Of  TCB  Relevant  Ada  Constructs  and  Features  To 
me  Reference  Manual  For  me  Ada  PnoqraiiTOina  Language 


CXxtput_Buffer_Pointer  := 

CXxtput_Buf  f  er_Pointer  nod 
Mcix_Size_of_mternal_Input_Buffer  +  1; 

Buffer_Count  :=  Buffer_Oount  -  1; 
end  if; 

end  Get_Character_f  raxi_mterrupt_Input_Address  ; 
or 

when  Buffer_Count  < 

Max_Size_of_Internal_Input_Buffer  -> 

accept  Save_Hardware_Buffer_Qiaracter  ( 
Cther_Task_MAC_Record  :  in 

Mandatory_Access__Control_Types_Package . 
MAC_Record_Type  )  do  —  see  3  -  3.1.3 

if  Mandatory_AccessjCtontrol_Manager_Package. 

Sens  it  ivity_Labels_Match  —  see  3  -  3.1.3 

(  Ixx^_Input jmskJ^CJ^ecxDrd . 
Sensitivity_Label 
Other _Task_MAC_Record . 

SensitivityJLabel  )  then 

Audit_Trail_Manager_Package .  —  see  3  -  3.2.3 

Log_Subj ects_Access_to_Obj ect_in_Audit_Trail  ( 
Local_][i^x±jrask_MACJRecord , 
Other_Task_MACJRecord  ) ; 

Intemal_Input_Buffer  ( 

Input_Buffer_Po inter  )  := 

Hardware j3raracter_Buf  f  er  ? 

Input_Buffer_Pointer  ;= 

Input_Buffer_Po  inter  mod 
Max_Size_of_Intemal_Input_Buffer  +  1; 

Buffer_Count  ;=  Buffer_Count  +  1; 
aid  if; 

end  Save_Hardware_Buffer_Character; 
end  select? 
end  loop; 

end  mterrupt_Input_Handler_Task; 
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task  body  mterruptjOutput_Handler_Task  is 

Max_Sizejof_Internal_Output_Buffer  :  constant  POSITIVE 
:=  64; 

InternaljDutput_Buffer  : 

array  (  1  ..  Max_Size_of_InternalJDutput_Buffer  ) 

Of  CHARACTER; 

Input_Buffer_Pointer  :  POSITIVE  :=  1;  ■ 
Output__Buffer_Po inter  :  POSITIVE  :=  1; 

BufferjOount  :  INTEGER  :=  1; 

HardwarejCharacter_Buffer  :  CHARACTER; 

for  Hardware j3iaracter_Buffer  use  at  16#0200 #; 

Hardware_Character_Buffer_is_Enpty  :  BOOLEAN  :=  TRUE; 


Local_OutputJTask_MAC_Record  : 

Mandatory_Access_Corrtrol  Jiypes_Package .  —  see  3  -  3.1.3 

MAC_Record_Type ; 


Other_Task_MAC_Record  ; 

Mandatory_Access_Cor.trol_iypes__Package .  —  see  3  -  3.1.3 

MAC_Record_Type ; 


begin  —  mterrupt_Output_Handler_Task 
loop 
select 

accept  Deposit_Character_into_Hardware_Buffer  ( 
Other_Task_MAC_Record  :  in 

Mandatory_Access_ContxolJiypes_Package . 

KAC_Record_Type  )  do  —  see  3  -  3.1.3 

if  Mandatory_Access_Control_Manager_Package. 

Sens  it  ivity_Labels_Matdn  —  see  3  -  3.1.3 

(  local jOJt5Xit_Task_MAC_Record. 
Sensitivity_Label , 

Other_Task_MAC_Recc'rd . 

Sens  it  ivity_Label  )  then 

Audit _Trail_Manager_Package .  —  see  3  -  3.2.3 

Log_Sub j  ects_Access_to_Ob j  ect_in_Audit_Tra i 1  ( 
Iocal_OutputJTask_MAC_Record , 

Other JTask_MAC_Record  ) ; 
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if  Buffer_Count  >  0  then 

Harravrare_Character_Buffer  := 
Internal_CXrtput_Buffer  ( 

CXrtput_Buffer_Po  inter  ) ; 

Cutput_Buffer_Po inter  := 

<Xitput_Buffer_Pointer  nod 
Max_Size_of_InternaljCXrtput_Buffer  +  1; 

Buffer_Count  :=  BufferjOount  -  1; 

else 

Hardware_Character_Buffer_is_Ernpty  :=  TRUE; 
end  if; 
end  if; 

end  Depos  it j3iaracter_into Jlarcfcrare_Buf  f  er ; 
or 

when  BufferjOount  < 

Max_Size_of_Intemal_Output_Buffer  => 

accept  Put_Oiaract^_into_InterruptjOutput_Address 
(  Char  :  in  CHARACTER; 

Other JTask_MAC_Record  ;  in 

Mandatory_Access_Q3ntroljrypes_Package . 
MAC_Reoord_Type  )  do  see  3  3*1.3 

if  Mandatory_Access_Control_Manager_Package. 

Sensitivity_Iabels_Match  —  see  3  -  3.1.3 

(  Local_Outp-Jt_Task_MAC_Record. 
Sensitivity_Label , 

Other JTask_MAC_Record . 

Sensitivity_Label  )  then 

AuditJTrail_Manager_Package .  —  see  3  -  3.2.3 

Iog_Sub j  ects_Access_to_Ob j  ect_in_Audit_Trail  ( 
Iocal_Output_Task_MAC_Record , 

Other  JTask_MAG_Record  ) ; 

InternaljOutput_Buf fer  ( 

Input_Buffer_Pointer  )  :=  Char; 


C-86 


APPENDIX  C 

Mapping  Of  TCB  Relevant  Ada  Constructs  aryl  Features  To 
Tne  Reference  Manual  For  The  Ada  Prooraiminc  Language 


Input_Buffer_Pointer  := 

Input_Buffer_Po inter  mod 
Max_Sizejof_Internal_CXrt¥Ut_Buffer  +  1; 

BufferjCount  :=  BufferjCount  +  1; 

if  Hardware  j3iaracter_Buf  f er_is__Enpty  then 


Hardware_Character_Buffer  := 

.  Internaljcxitput_Buffer( 
Output_Buffer_Fointer  )  ? 

Output JBufferJtointer  := 

Output_Buf  f  er_Pointer  mod 
Max_Size_of_Intemal_Output_Buffer  +  1; 

BufferjCount  :=  BufferjCount  -  1? 


Hazdwarej2iaracter_Buffer_is_Empty  :=  TRUE; 
end  if; 
end  if; 

end  Put_C5iarac±er_into_Interrupt_Output_Address  ; 
end  select; 
end  loop; 

end  Int^nrpt jOutput_Handler_Task ; 
end  Interrupt_Handler_Package ; 


2  -  13.6  Change  of  Representation 

Hie  change  of  representation  clauses  introduces  potential  problems  similar 
to  those  associated  with  type  conversion  (Section  2  -  4.6) . 

Guideline: 

1.  The  change  of  any  representation  clause  should  be  monitored  during 
design  reviews  and  code  walkthroughs. 


2  -  13.7  The  Package  System 

No  Ada-specific  inpact  on  TCBs 
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2  ~  13.7.1  System-Dependent  Named  Numbers 
No  Ada-specific  inpact  on  TCBs 


2  -  13.7.2  Representation  Attributes 

No  Ada-specific  inpact  on  TCBs 


2  -  13.7.3  Representation  Attributes  of  Real  Types 
No  Ada-specific  inpact  on  TCBs 


2  -  13.8  Machine  Code  Insertions 

One  use  of  this  feature  is  to  insert  calls  to  currently  existing  functions 
(e.g. ,  sort  routines) .  A  specification  of  the  routines  at  the  Ada 
specification  language  level  and  establishing  that  the  routines  do  not  stray 
from  their  specified  behavior  are  necessary  prerequisites  to  use  of  machine 
code  insertions. 

Guideline: 

1.  New  software  components  that  have  traditionally  been  written  in  machine 
code  (e.g.,  device  drivers  which  handle  sensitivity  labels  in  input  or 
output  operations)  should  be  written  in  Ada.  If  "trusted"  machine  code 
already  exists,  then  it  may  be  acceptable  to  use  it  rather  than  writing 
new  Ada  code. 


2-13.9  Interface  to  Other  Languages 

Ada  provides  the  means  to  interface  with  other  languages  using  the  pragma 
INTERFACE.  Using  multiple  high-order  languages,  or  using  assembly  language 
with  a  high-order  language,  makes  a  system  more  difficult  to  understand. 
The  difficulty  here  is  not  with  the  pragma  INTERFACE  per  se,  but  rather  with 
using  more  than  one  language  in  a  system. 


Guideline: 

1.  Avoid  interfacing  Ada  with  another  language. 
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Exanple:  This  example  illustrates  the  interface  of  Ada  with  Pascal. 

package  Graphics_Library_Package  is 
procedure  Draw_Circle 

(  Center  :  in  Coordinates_Type ; 

Radius  :  in  Distanoe_Type  ) ; 


private 

pragma  INTERFACE  (  PASCAL,  Draw_Circle  ) ; 


end  Graphics_Library_Package ; 


2  -  13.10  Unchecked  Progranming 

Ada  provides  two  unchecked  programing  features,  unchecked  storage 
deallocation  and  unchecked  type  conversion.  "The  predefined  generic  library 
subprograms  UNCHECKED_DEALIOCATTON  and  UNCHKXED_OONVERSION  are  used  for 
unchecked  storage  deallocation  and  for  unchecked  type  conversions" 
?  ANSI/MIIr-STD-1815A-1983 ] . 


2  -  13.10.1  Unchecked  Storage  Deallocation 

The  only  program-visible  effect  of  using  uncheckedjdeallocation  is  the 
assignment  of  the  access  value  null  to  the  variable  being  deallocated.  This 
does  not  ensure  that  the  variable  is  scrubbed  before  it  is  deallocated. 

Guideline: 

1.  Avoid  using  the  unchecked  programming  feature  UNCHECKED_DEAIJ.OCA.TION . 


2  -  13.10.2  Unchecked  Type  Conversions 

One  major  difficulty  with  the  use  of  unchecked  type  conversions  is 
specifying  the  transformation  between  the  two  types  that  takes  place  during 
the  conversion. 


Guideline: 

1.  Avoid  using  the  unchecked  programming  feature  UNCHECKED_CONVERSION. 
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2-14.  Input-Output 

This  chapter  of  the  IW4  describes  the  mechanisms  for  input  and  output  for  an 
Ada  program  and  the  management  of  file  objects.  The  packages  described 
include  procedures  for  the  input  of  sequential,  direct,  numeric  data,  and 
enumeration  data.  A  general  discussion  of  input  and  output  operations  is 
located  in  this  section. 

The  major  obstacles  to  input  and  output  are  the  lack  of  the  semantics  of 
input  and  output,  and  the  ability  to  do  input  and  output  anywhere  within  an 
Ada  program. 

An  example  for  handling  input  and  output  is  provided  in  Section  2  -  14.7. 


Guidelines: 

1.  Minimize  the  use  of  input  and  output  [ASOS  1987]. 

2.  Security  aspects  of  all  input  and  output  operations,  such  as 
maintaining  the  secrecy  of  the  information  between  the  TCB  and 
displays,  disks,  and  tapes,  should  be  addressed  as  early  as  possible  in 
the  development  of  a  TCB  system,  preferably  in  its  requirements 
specification. 

3.  The  security  of  the  TCB's  input  and  output  functions  should  be  provided 
with  discretionary  access  controls  (e.g. ,  access  control  lists)  and/or 
mandatory  access  controls  (e.g. ,  sensitivity  labels) .  All  inputs  to 
and  outputs  from  a  TCB  should  be  logged  in  the  audit  trail. 

4.  Security  aspects  of  input  and  output  operations  should  be  addressed  as 
early  as  possible  in  the  development  of  a  TCB  system,  preferably  in  its 
requirement  specifications.  These  operations  should  be  conscientiously 
implemented  as  stipulated  by  the  TCB  system's  requirements 
specification,  preliminary  and  detailed  design  reviews  and  code 
walkthroughs . 


2  -  14.1  External  Files  and  File  Objects 

No  additional  Ada-specific  inpact  on  TCBs 

2  -  14.2  Sequential  and  Direct  Files 

No  additional  Ada-specific  inpact  on  TCBs 
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2  -  14.2.1  File  Management 

No  additional  Ada-specific  inpact  on  TCBs 

2  -  14.2.2  Sequential  Input-Output 

No  additional  Ada-specific  inpact  on  TCBs 

2  -  14.2.3  Specification  of  the  Package  Sequential_IO 
No  additional  Ada-specific  inpact  on  TCBs 

2  -  14.2.4  Direct  Input-Output 

No  additional  Ada-specific  inpact  on  TCBs 

2  -  14.2.5  Specification  of  the  Package  Direct_IO 
No  additional  Ada-specific  impact  on  TCBs 

2  -  14.3  Text  Irput-CXitput 

No  additional  Ada-specific  inpact  on  TCBs 

2  -  14.3.1  File  Management 

No  additional  Ada-specific  impact  on  TCBs 

2  -  14.3.2  Default  Input  and  Output  Files 

No  additional  Ada-specific  inpact  on  TCBs 

2  -  14.3.3  Specification  of  Line  and  Page  Lengths 
No  additional  Ada-specific  inpact  on  TCBs 
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2  -  14.3.4  Operations  on  Columns,  Lines,  and  Pages 
No  additional  Ada-specific  inpact  on  TCBs 

2  -  14.3.5  Get  and  Put  Procedures 

No  additional  Ada-specific  inpact  on  TCBs 

2  -  14.3.6  Input-Output  of  Characters  and  Strings 
No  additional  Ada-specific  inpact  on  TCBs 

2  -  14.3.7  Input-Output  for  Integer  lypes 

No  additional  Ada-specific  inpact  on  TCBs 

2  -  14.3.8  Input-Output  far  Real  Types 

No  additional  Ada-specific  inpact  on  TCBs 

2  -  14.3.9  Input-Oitput  for  Enumeration  Types 
No  additional  Ada-specific  impact  on  TCBs 

2  -  14.3.10  Specification  of  the  Package  Text_I0 
No  additional  Ada-specific  impact  on  TCBs 

2  -  14.4  Exceptions  in  Input-Output 

No  additional  Ada-specific  impact  on  TCBs 

2  -  14.5  Specification  of  the  Package  IO_Exceptions 
No  additional  Ada-specific  impact  on  TCBs 
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2  -  14.6  low  Level  Input-Output 

No  additional  Ada-specific  impact  on  TCBs 

2  -  14.7  Example  of  Input-Output 

Example:  This  example  illustrates  trusted  input  and  output, 
with  TEXT_IO; 

with  Mcindatory_Access_Control_Types_Package ;  —  see  3  -  3.1.3 

with  Aocess_Ct^trol_List_Types_Package ; 

generic 

Max_Characters_in_Message  :  POSITIVE  :=  80; 
package  Generic_Sensitive_Text_File_Manager_Package  is 
Sens  it ive_Text_File  :  TEXT_I0.  FUEJIYFE; 

subtype  Message  Type  is  STRING  (  1  . .  Max_Characters_in_Message  ) ; 


procedure  Put_Line  ( 

Sub j  ect_MAC_Record  :  in 

Mandatory_Acoess_Control_Types_Package . 
MAC_Record_Type ; 

Naroed_0b j  ect_MAC_Record  :  in 

Mandatory_Access_Control_Types_Package . 
MAC_Record_Type ; 

Message  :  in  Message_Type  ) ; 


end  Generic_Sensitive_Text_File_Manager_Package ; 


with  Mandatory_Access_Control_Manager_Package;  —  see  3 
with  Audit_Trail_Manager_Package?  —  see  3 
package  Generic_Sensitive_Text_File_Manager_Package  is 


3-1.3 

3.2.3 


C-93 


APPENDIX  C 

Mapping  Of  TCB  Relevant  Ada  Constructs  and  Features  To 
Ihe  Reference  Manual  For  The  Ada  Proqrararrma  Language 


procedure  Put_Line  ( 

Subject_MAC_Record  :  in 

Mandatory_Aooess_Control_Types_Package . 

MAC Jtecord Jiype ; 

Naraed_Ob  j  ect_MAC_Reoord  :  in 
Mandatory J\cx^s_Oontrol_Types_Package . 

MAC_Record_Type ? 

Message  :  in  Message__Type  )  is 

begin  —  Put_Line 

if  Mandatory_Access_Control_Manager_Package. 

Sensitivity_Iabels_Match  —  see  3  -  3.1.3 

(  Sub j  ect_MAC_Reoord .  Sensitivity_Label , 

NamedjOb  j  ect_MAC_Record .  Sensitivity_Iabel  )  then 

Audit JErail_Manager_Package.  —  see  3  -  3.2.3 

Log_Sub j  eicts_AccessjtojOb j  ect_in_Audit_Trail  ( 
Subject_MACJReoord,  Naned_Ob j ecrt_MAC_Record  ) ; 

TEXT_IO.  FUT_LINE  (  SensitiveJPext_File ,  Message  )  ? 

end  if; 
end  Put  Line; 


end  Generic_Sensitive_Text_File_Manager_Package; 
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2.1  Tailoring  and  Configuring  Ada  Compiler  and  Runtime  System 

This  section  does  not  have  a  corresponding  chapter  in  the  LEM.  Nevertheless,  it 
is  an  important  issue  that  should  be  addressed  in  the  software  development  of  TCB 
systems. 


Tailoring  an  Ada  compiler  or  runtime  system  is  the  actual  modification  of  the 
code  of  the  Ada  compilation  system  [Baker  1988].  Configuration  of  an  Ada 
compiler  or  runtime  system  is  the  reselection  of  compiler  options  and  parameters 
provided  Joy  the  Ada  compiler  vendor.  Tailoring  and  configuration  may  allow  a 
compiler  or  runtime  system  to  run  conveniently  on  various  host  and  target 
combinations.  The  compiler  will  no  longer  be  validated,  however,  and  other 
problems  may  be  introduced  during  the  tailoring  or  configuring  process. 
Modifying  the  Ada  compiler  or  runtime  system  of  a  TCB  by  tailoring  or  configuring 
should  be  avoided. 


Guidelines: 

1.  Any  tailoring  or  configuring  of  the  Ada  compiler  or  runtime  system  must  be 
done  under  the  supervision  of  and  with  the  approval  of  the  TCB  system 
security  administrator. 

2.  Security  aspects  of  ary  tailoring  of  an  Ada  compiler  or  runtime  system 
should  be  addressed  as  early  as  possible  in  the  development  of  a  TCB  system, 
preferably  in  its  requirements  specification. 

3 .  Any  element  of  an  Ada  runtime  environment  that  is  tailored  should  be 
subjected  to  the  same  evaluation  criteria  that  are  applied  to  the  TCB  being 
developed. 
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3.  C  MAPPING  OF  ADA  USAGE  TO  TCB  CRITERIA. 


This  section  provides  a  mapping  of  Ada  constructs  that  would  be  appropriate  to 
the  implementation  of  the  TCB  structures  and  functions  defined  in  the  TCSEC.  The 
class  B3  criteria  are  used  as  the  template  of  the  generalized  TCB  criteria, 
because  they  are  the  highest  level  of  security  criteria  under  consideration. 
Also,  the  Ada  constructs  mapped  to  these  criteria  can  similarly  be  mapped  to  the 
TCB  criteria  of  lower  security  classes.  The  four  TCB  criteria  subsections 
considered  are  Security  Policy,  Accountability,  Assurance,  and  Documentation. 
For  further  discussion  of  the  various  topics,  refer  to  the  TCSEC . 


GENERALIZED  TCB  CRITERIA 

"The  class  B3  TCB  must  satisfy  the  reference  monitor  requirements  that  it  mediate 
all  accesses  of  objects,  be  tamperproof,  and  be  small  enough  to  be  subjected  to 
analysis  and  tests.  To  this  end,  the  TCB  is  structured  to  exclude  code  not 
essential  to  security  policy  enforcement,  with  significant  system  engineering 
during  TCB  design  and  implementation  directed  toward  minimizing  its  complexity. 
A  security  administrator  is  supported,  audit  mechanisms  are  expanded  to  signal 
security-relevant  events,  and  system  recovery  procedures  are  required.  The 
system  is  hi^ily  resistant  to  penetration." 


3.1  Security  Policy 

A  security  policy  describes  hew  users  may  access  documents  or  other  information. 
It  is  the  set  of  laws,  rules,  and  practices  that  regulate  hew  an  organization 
manages,  protects,  and  distributes  sensitive  information. 


3.1.1  Discretionary  Access  Control 

Discretionary  access  control  provides  a  means  of  restrict  Lag  access  to  objects 
based  on  the  identity  of  subjects  and/or  groups  to  which  they  belong.  The 
controls  are  discretionary  in  the  sense  that  a  subject  with  a  certain  access 
permission  is  capable  of  passing  that  permission  (perhaps  indirectly)  to  any 
other  subject  (unless  restrained  by  mandatory  access  control) .  An  enforcement 
mechanism  (e.g. ,  access  control  lists)  must  allcw  users  specify  and  control 
sharing  of  those  objects  and  must  provide  controls  to  limit  propagation  of  access 
rights. 
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Guidelines  for  the  use  of  Ada  Constructs  and  Features: 

Enforcement  mechanisms  that  consist  of  lists,  such  as  access  control  lists, 
should  be  created  with  linked  lists  and  queues,  using  either  static  or 
dynamic  storage  constructs  (e.g. ,  using  arrays  or  access  types, 
respectively) .  Though  linked  lists  and  queues  are  more  typically 
implemented  using  dynamic  storage  constructs  created  with  Ada's  access 
types,  which  provide  more  efficient  memory  usage,  linked  lists  and  queues 
created  with  arrays  provide  more  efficient  execution.  In  addition,  the  lists 
should  be  represented  by  abstract  data  types,  which  consist  of  Ada's  strong 
data  typing  encapsulated  in  packages.  The  recommended  constructs  and  their 
discussion  in  Section  2.0  are  as  follows: 

ACCESS  TYPES  2  -  3.8 
ARRAYS  2  -  3.6 

PACKAGES  2-7. 

TYPES  2-3. 

Example:  This  example  illustrates  a  generic  package  specification  for 
multiple  instances  of  user  identification  and  authentication 
(The  package  body  is  in  Section  3  -  3.2.1.) 

with  Mandatory_AccessJ3ontrolJiypes_Package;  —  see  3  -  3.1.3 

with  Generic_Access_Control_List_Manager_Package ; 

generic 


type  Password_Type  is  private; 


package  Generic_User_Identification_and_Authentication_Package  is 


procedure  Check_Password 

(  Password  :  in  Password  _Type; 

Local_MAC_Record  :  in 

Mandatory_Access_Control_Types_Pa.okage .  —  see  3  -  3.1.3 

MAC_Record_Type ; 

Password_is_Val id  :  out  BOOLEAN  ) ; 
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end  Generic_User_Identi  f  i  cat ion_and_Authent icat ior._Package ; 


Use  tasking  to  handle  concurrent  processes  in  more  carplex  TCB  systems  where 
multiuser  and  multisubject  requirements  (e.g. ,  simultaneously  monitoring 
accesses  to  control  lists  by  multiple  subjects)  are  present.  Tasks  are 
discussed  in  Section  2-9. 


When  nonvolatile  versions  of  major  lists  (e.g.,  access  lists,  need  to  be 
accessed  from  disk  or  tape)  protect,  the  security  of  input  and  output 
operations  with  protocols  that  satisfy  the  class  of  the  given  TCB.  Input 
and  output  is  discussed  in  Section  2-14. 


3.1.2  Object  Reuse 

Object  reuse  is  the  reassignment  to  seme  subject  of  a  medium  (e.g.,  page  frame 
disk  sector,  magnetic  tape)  that  contained  one  or  more  objects.  To  be  securely 
reassigned,  such  media  must  contain  no  residual  data  from  the  previously 
contained  object (s) .  Hie  TCB  must  assure  that  when  a  storage  object  is  initially 
assigned,  allocated,  or  reallocated  to  a  subject  from  the  TCB's  pool  of  unused 
storage  objects,  the  object  contains  no  data  for  which  the  subject  is  not 
authorized. 

Guidelines  for  the  use  of  Ada  Constructs  and  Features: 

The  reuse  of  objects  involves  the  management  of  memory  used  for  storing 
objects.  Dynamic  storage  as  well  as  static  storage  should  be  managed  in  a 
secure  manner.  Also,  objects  should  be  represented  by  abstract  data  types, 
which  are  implemented  with  Ada's  packages  and  user-defined  data  types.  Use 
tasking  and  shared  variables  as  required  to  manage  object  reuse  when 
concurrent  processes  are  warranted  for  efficient  multiuser  and  multisubject 
TCB ,  system  operation.  The  recommended  constructs  and  their  discussion  in 
Section  2.0  are  as  follows: 

ACCESS  TYPES  2 
ARRAYS  2 
PACKAGES  2 
TASKS  2 
TYPES  2 


3.1.3  labels 

A  sensitivity  label  is  a  piece  of  information  that  represents  the  security  level 
of  an  object  and  that  describes  the  sensitivity  (i.e.,  classification)  of  the 


-  3.8 

-  3.6 

-  7. 

-  9. 

-  3. 
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data  in  the  object.  Sensitivity  labels  are  used  by  the  TCB  as  the  basis  for 
mandatory  access  control  decisions.  They  are  associated  with  each  ADP  system 
resource  (a.g. ,  subject,  storage  object)  that  is  directly  or  indirectly 
accessible  by  subjects  external  to  the  TCB,  and  they  must  be  maintained  by  the 
TCB.  To  import  non-label ed  data,  the  TCB  must  request  and  receive  from  an 
authorized  user  the  security  level  of  the  data,  and  all  such  actions  must  be 
auditable  by  the  TCB.  Also,  the  TCB  must  enforce  subject  sensitivity  labels  and 
device  labels. 

Guidelines  far  the  use  of  Ada  Constructs  and  Features: 

Treat  sensitivity  labels  as  objects  that  are  represented  by  abstract  data 
types.  These  should  consist  of  Ada's  strong  data  typing  encapsulated  in 
packages.  The  exportation  of  labeled  information  typically  involves  input 
and  output  using  secure  protocols,  which  should  also  be  represented  by 
abstract  data  types.  Use  tasking  and  shared  variables  as  required  to  manage 
subject  sensitivity  labels  and  their  exportation  when  concurrent  processes 
are  warranted  for  efficient  multiuser  and  multisubject  TCB  system  operation. 
The  recommended  constructs  and  their  discussion  in  Section  2.0  are  as 
follows: 


INPUT  and  OUTPUT  2  -  14. 
PACKAGES  2-7. 

TASKS  2-9. 

TYPES  2-3. 


Example:  This  example  illustrates  sensitivity  label  type  declaration. 

with  Basic  JTCB_Types_Package ; 

package  Mandatory_Access_Control_Types_Package  is 


subtype  Name_of_Resource_Type  is 

Bas  ic_TCB_'iypes_Package .  Name_String_Type  ; 

subtype  Sens  itivity_Label_Type  is 

Bas ic_TCB_Types_Package .  Name_String_Type; 

Scrubbed_Sens it ivity_Label  :  Sens it ivity_Label_Type 
:=  BasicJTCB_Types_Package.  Blank_Name_String; 

subtype  Exception_Name_Type  is 

Basic_TCB_Types_Package .  Name_String_Type ; 
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Scrubbed_Except  ion_Name  :  Exception_Name_Type 
:=  Basic_TCB_Types_Package.  Blank_Name_String; 

Others_String  :  Bas  ic_TCB_Types_Package .  Naine_String_'IVpe 
:=  Basic_TCBJiypes_Package .  Blank_Naine_String ; 

type  MAC_RecxDrd_Type  is 
record 

Name  *  Name_of_Resource_Type 

:=  Basic JICB_iypes_Package .  Blank_Name_String;  —  see  2  -  3.2.1 

Sensitivity_Label  :  Sens  it  ivi  ty_Iabel_Type 
:=  Scrubbed_Sensitivity_Label ; 


end  record; 


•  •  • 

end  Mardatoiy_Acx»ss_Control_Types_Pac}cage ; 


with  Basic  JTCB_Types_Package ; 

with  Mandatory_Access_ControlJIVpes_Package ; 

package  Mandatory_Aooess_Control_Manager_Package  is 


function  Sensitivity_Iabels_Match 
(  Sensitivity_Label_A  :  in 

Mandatory_Access_Ctontrol_TVpes_Package . 
Sensitivity_Label_Type ; 

Sensitivity_Label_B  :  in 
Mandatory_Access_Control_Types_Package . 
Sensitivity_Label_Type  ) 

return  BOOLEAN; 


end  K  andatory_Access_Control_Manager_Package ; 
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3.1.4  Mandatory  Access  Control 

A  mandatory  access  control  is  a  means  of  restricting  access  to  objects  based  on 
the  sensitivity  (as  represented  by  a  label)  of  the  information  contained  in  the 
objects  and  the  formal  authorization  (i.e.,  clearance)  of  subjects  to  access 
information  of  such  sensitivity.  It  prevents  "sane  types  of  Trojan  horse  attacks 
by  imposing  access  restrictions  that  cannot  be  bypassed,  even  indirectly.  Under 
mandatory  controls,  the  system  assigns  both  subjects  and  objects  special 
attributes  that  cannot  be  changed  on  request  as  can  discretionary'  access  control 
attributes  such  as  access  control  lists.  The  system  decides  whether  a  subject 
can  access  an  object  by  comparing  their  security  attributes"  [Gasser  1988, 
p.61] .  Thus,  a  TCB  must  enforce  a  mandatory  access  control  policy  over  all 
resources  (i.e.,  subjects,  storage  objects  and  I/O  devices)  that  are  directly  or 
indirectly  accessible  by  subjects  external  to  the  TCB.  All  subjects  and  storage 
objects  must  be  assigned  sensitivity  labels  that  are  a  combination  of 
hierarchical  classification  levels  and  non-hierarchical  categories,  and  the 
labels  must  be  the  basis  of  the  mandatory  access  control  decisions.  Also,  a  TCB 
must  be  able  to  support  two  or  more  security  levels. 

Guidelines  far  the  use  of  Ada  Constructs  and  Features: 

The  management  of  a  mandatory  access  control  policy  is  performed  typically 
with  an  implementation  of  the  Bell  and  LaPadula  security  model  that 
regulates  the  security  of  the  accessing  of  objects  by  subjects  and  the 
assignment  of  sensitivity  labels  to  enforce  the  policy.  This  requires 
classifications  of  the  objects  which  are  to  be  protected  by  this  policy. 
Manage  dynamic  storage  as  well  as  static  storage  in  a  secure  manner.  Also, 
objects  should  be  represented  by  abstract  data  types,  which  are  implemented 
with  Ada's  packages  and  user-defined  data  types.  Similarly,  the  policy 
itself  should  be  represented  by  a  package.  Use  tasking  and  shared  variables 
as  required  to  manage  mandatory  access  controls  when  concurrent  processes 
are  warranted  for  efficient  multiuser  and  multisubject  TCB  system  operation. 
The  recommended  constructs  and  their  discussion  in  Section  2.0  are  as 
follows: 

ACCESS  TYPES 
ARRAYS 
PACKAGES 
TASKS 
TYPES 


3.2  Accountability 

Accountability  is  the  monitoring  of  access  to  and  operation  of  a  TCB  system  by 
using  identification  and  authentication  of  users  requesting  access  to  the  system, 
maintenance  of  trusted  communication  paths,  and  auditing  of  accesses  to  the  TCB. 


2  -  3.8 
2  -  3.6 
2-7. 
2-9. 
2-3. 
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3.2.1  Identification  and  Authentication 

Identification  consists  of  using  unique  identifiers  that  are  associated  with  each 
user  (such  as  a  last  name,  initials,  or  account  number)  that  everyone  knows,  that 
nobody  can  forge  or  change,  and  that  all  access  requests  can  be  checked  against. 
The  identifier  is  the  means  by  which  the  system  distinguishes  users.  In 
particular,  a  TCB  must  require  users  to  identify  themselves  to  it  before 
beginning  to  perform  any  other,  actions  that  the  TCB  is  expected  to  mediate. 

Authentication  consists  of  associating  a  real  user  (or  more  accurately,  a  program 
running  on  behalf  of  a  user)  with  a  unique  identifier,  namely,  the  user  ID.  "The 
system  must  separate  authentication  information  (passwords)  from  identification 
information  (unique  IDs)  to  the  maximum  extent  possible,  because  passwords  are 
secret  and  user  IDs  are  public"  [Gasser  1988,  p.23] .  A  TCB  must  maintain 
authentication  data  that  includes  information  for  verifying  the  identity  of 
individual  users  as  well  as  information  for  determining  the  clearance  and 
authorizations  of  individual  users.  It  uses  this  data  to  authenticate  the  user's 
identity  and  to  determine  the  security  level  and  authorizations  of  subjects  that 
are  created  to  act  on  the  behalf  of  the  individual  user.  The  TCB  must  protect 
authentication  data  so  that  it  cannot  be  accessed  by  an  unauthorized  user.  It 
must  be  able  to  enforce  individual  accountability  by  providing  the  capability  to 
uniquely  identify  each  individual  ADP  system  user.  Also,  it  must  provide  the 
capability  of  associating  the  individual  identity  with  all  auditable  actions 
taken  by  that  individual. 

Guidelines  for  the  use  of  Ada  Constructs  and  Features: 

Manage  identification  and  authentication  data  using  corresponding  abstract 
data  types,  which  consist  of  Ada's  strong  data  typing  encapsulated  in 
packages.  This  management  should  also  include  using  dynamic  storage  as  well 
as  static  storage  in  a  secure  manner.  Similarly,  the  identification  and 
authentication  processes  should  be  represented  by  packages.  Use  tasking  and 
shared  variables  as  required  to  manage  security  data  when  concurrent 
processes  are  warranted  for  efficient  multiuser  and  multisubject  TCB  system 
operation.  The  recommended  constructs  and  their  discussion  in  Section  2.0 
are  as  follows: 


ACCESS  TYPES 

2  -  3.8 

ARRAYS 

2  -  3.6 

PACKAGES 

2-7. 

TASKS 

2-9. 

TYPES 

2-3. 
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Example:  Tiiis  example  illustrates  a  generic  package  body  for  multiple 
instances  of  user  identification  and  authentication.  (The 
package  specification  is  in  Section  3  -  3.1.1.) 

with  Access_Control_List_Types_Package ; 

with  Audit_Trail_Manager_Package ;  —  see  3  -  3.2.3 

parfcagg*  body  Generic_User JEderrtif  ication_and_Authentication_Package  is 


procedure  Check_Password 

(  Password  :  in  PasswordJType; 

Lxxal_MAC_Record  :  in 

Mandatory_Access_Ctontrol_TVpes_Package .  —  see  3  -  3.1.3 

MAC_Fecord_rype ; 


Password_is_Valid  :  out  BOOLEAN  )  is 


begin  —  CheckJPassword 


end  Check_Password ; 


end  Generic_User_Identification_and_Authentication_Package  ; 


3.2.2  Trusted  Path 

A  trusted  path  is  a  mechanism  by  which  a  person  at  a  terminal  can  communicate 
directly  with  the  TCB.  This  mechanism  can  only  be  activated  by  the  person  or  the 
TCB  and  cannot  be  imitated  by  unevaluated  software.  A  TCB  must  support  a  trusted 
cxranunication  path  between  itself  and  users  for  use  when  a  positive  TCB-to-user 
connection  is  required  (e.g.;  login,  change  subject  security  level). 
Communication  via  this  trusted  path  must  be  activated  either  by  a  user  or  the  TCB 
and  must  be  logically  isolated  and  unmistakably  distinguishable  from  other  paths. 
The  Trusted  Path  for  a  Class  B3  TCB  needs  to  allow  bi-directional  access,  from 
user  to  TCB  and  from  TCB  to  user. 
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Guidelines  for  the  use  of  Ada  Constructs  and  Features: 

Trusted  paths  require  secure  input  and  output  ccnrurdcatian  paths  between 
the  user  and  subject  and  the  TCB.  Trusted  paths  should  be  treated  as 
objects,  which  can  be  represented  by  abstract  data  types.  These  should 
consist  of  Ada's  strong  data  typing  encapsulated  in  packages.  Use  tasking 
and  shared  variables  as  required  to  manage  trusted  paths  when  concurrent 
processes  are  warranted  for  efficient  multiuser  and  mu]  t.isubject  TCB  system 
operation.  The  recommended  constructs  and  their  discussion  in  Section  2.0 
are  as  follows: 

INPUT  and  OUTPUT 
PACKAGES 
TASKS 
TYPES 


3.2.3  Audit 

An  audit  of  accesses  to  and  operation  of  TCB  operation  is  maintained  in  a  set  of 
records  (i.e. ,  an  audit  trail)  that  collectively  provide  documentary  evidence  of 
processing  used  to  aid  in  tracing  from  original  transactions  forward  to  related 
records  and  reports,  and/or  backwards  from  records  and  reports  to  their  component 
source  transactions.  The  TCB  must  be  able  to  create,  maintain,  and  protect  from 
modification  or  unauthorized  access  or  destruction  an  audit  trail  of  accesses  to 
the  objects  it  protects.  Audit  data  must  be  protected  by  the  TCB  so  that  read 
access  to  it  is  limited  to  those  who  are  authorized  for  audit  data.  A  TCB  must 
be  able  to  record  use  of  identification  and  authentication  mechanisms, 
introduction  of  objects  into  a  user's  address  space,  deletion  of  objects,  actions 
taken  by  computer  operators  and  system  administrators  and/or  system  security 
officers,  and  other  security  relevant  events.  A  TCB  must  be  able  to  audit  any 
override  of  human-readable  output  markings.  For  each  recorded  event,  the  audit 
record  must  identify  date  and  time  of  event,  user,  type  of  event,  and  success  or 
failure  of  the  event.  For  identification  and  authentication  events,  the  audit 
record  must  include  origin  of  request  (terminal  ID) .  For  events  that  introduce 
an  object  into  a  user's  address  space  and  for  object  deletion  events,  the  audit 
record  must  include  the  name  of  the  object  and  the  object's  security  level.  The 
ADP  system  administrator  must  be  able  to  selectively  audit  the  actions  of  any  one 
or  more  users  based  on  individual  identity  and/or  object  security  level.  A  TCB 
must  be  able  to  audit  the  identified  events  that  may  be  used  in  the  exploitation 
of  covert  storage  channels.  A  TCB  must  contain  a  mechanism  that  is  able  to 
monitor  the  occurrence  or  accumulation  of  security  auditable  events  that  may 
indicate  an  imminent  violation  of  security  policy;  this  mechanism  must  be  able  to 
immediately  notify  the  security  administrator  when  thresholds  are  exceeded.  If 
the  occurrence  or  accumulation  of  these  security  relevant  events  continues,  the 
system  must  take  the  least  disruptive  action  to  terminate  the  event. 


2-14 

2-7. 

2-9. 

2-3. 
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Guidelines  for  the  use  of  Ada  Constructs  and  Features: 

Managing  audit  data  requires  maintaining  an  audit  trail.  An  audit  trail  is 
typically  recorded  on  disk  and/or  tape,  which  requires  secure  input  and 
output  cornmunication  paths  within  a  TCB  that  includes  a  secure  disk  and/or 
tape.  The  audit  data  and  audit  trail  should  be  treated  as  objects,  which 
can  be  represented  by  abstract  data  types.  These  should  consist  of  Ada's 
strong  data  typing  encapsulated  in  packages.  In  addition  to  being  stored  on 
disk  or  tape,  the  audit  data  should  be  (at  least  partially)  located  in 
dynamic  storage  or  static  storage.  Use  tasking  and  shared  variables  as 
required  to  manage  the  audit  data  and  audit  trail  when  concurrent  processes 
are  warranted  for  efficient  multiuser  and  multisubject  TCB  system  operation. 
The  reocninended  constructs  and  their  discussion  in  Section  2.0  are  as 
follows: 


ACCESS  TYPES  2  -  3.8 

ARRAYS  2  -  3.6 

INFUT  and  OOTEUT  2-14 
PACKAGES  2-7. 

TASKS  2-9. 

TYPES  2-3. 


Example:  Audit  trail  manager  package 
with  TEXT_IO; 

with  Mandatory_Access_Control_Types_Package;  —  see  3  -  3.1.3 

package  Audit_Trail_Manager_Package  is 


Audit_Trail_Text__File  :  TEXTJEO.  FILE_TYPE; 


procedure  Log_Sub j  ects_Access_to_Cto j  ect_in_Audit_Trail  ( 
Subject_MAC_Record  :  in 

Mandatory_Access_Control_Types_Package.  —  see  3  -  3.1.3 

MAC_Record_Type ; 

NamedjOb j  ect_MAC_Record  :  in 

Mandatory_AccessjControlJTypes_Package .  —  see  3  -  3.1.3 

MAC  Record  Type  ) ? 
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procedure  Log_Exception_in_Audit_Trail  ( 

Exception_Name  :  in 

Mandatory_Access_Control_Typ>es_Package .  —  see  3  -  3.1.3 

Exception Jteme_Type ; 

Exception_Raiser_Record  :  in 

Mandatory_Aa3ess_Ctntrol_'IVpes_Pac)cage .  —  see  3  -  3.1.3 

MAC_Record_Type ; 

Exception_Hajidler_Record  :  in 

MarKiatory_Acoess_Control_'IVpes_Package.  —  see  3  -  3.1.3 

MAC_Record_Type  ) ; 

*  * r"  •  •  • 

end  Andit_Trail_Manager_Package ; 


with  Marriatory_Access_Control_Manager_Package  ; 
package  body  Auiit_Trail_Manager_Package  is 


procedure  Log_Sub j  ects_Access_to_Ob j  ect_:ln_Audit_Trail  ( 

Sub j  ect_MAC_Record  :  in 

MarKiatory_AooessjCk)ntroljrypes_Package.  —  see  3  -  3.1.3 
MAC_Record_'IYpe  ; 

Named_Ctoject_MAC_Eecord  :  in 

Mandatory_Access_Control_Types_Package .  —  see  3  -  3.1.3 

MACJRecord_Type  )  is 


begin  —  Iog_Sub  j  ects_Access__to_CP  j  ecr_in_Audit_Trail 


TEXT_IO.  R7T_UNE  (  Audit_Trail_Text_File, 

"Subject  "  &  Sub j ect_MAC_Record .  Name  ) ; 

TEXT_IO.  RJT_LINE  (  Audit_Trail_Text_File. 

"  is  not  authorized  to  access  "  & 
Named_Ob  j  ect_MAC_Record .  Name  ) ; 


end  Log_Subj  ects_Access_to_Obj  ect_in_Audit_Trail ; 
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prooedure  Lag_Exception  _in_AL>dit_Trail  ( 

Exception_Name  ~  :  in 

Mandatory_Acx»ss_Oontrol Jiypes_Package .  —  see  3  -  3.1.3 

Exception_Name_Type ; 

Exception_Raiser_Record  :  in 

Mandatory_A!Ocess_Control_Types__Package .  —  see  3  -  3.1.3 

MAC_Reccrd_Type ; 

Exoeption_HarrilerJRacord  :  in 

MarKiatory_Aa3ess_Ctontrol_TVpes_Package.  —  see  3  -  3.1.3 
MAC_Record_Type  )  is 

•  •  • 

begin  —  Lag_Exc^tion_in_Auditjrrail 


if  Mandatory_Acc^ss_Control__Manager_Package . 

Sensitivity_Labels_Match  —  see  3  -  3.1.3 

(  Exception_Handler__Recx)rd . 

Sensitivity_Label , 

Exception Jlaiser_Record . 

Sensitivity_Label  )  then 

TEXT_IO.  K!T_IZNE  (  Audit_Trail_Text_File , 

"Subprogram  "  & 

Except ion_Handler_Record .  Name  & 

"  handled  the  exception,  "  ) ; 

TEXT_IO.  HJT_LINE  (  Audit_Trail_Text_File,  "  ",  & 

Except ion_Name  &  "  raised  by  "  & 
Exception_Raiser_Becord.  Name  ) ; 

else 

TEXT_IO.  RJT_LINE  (  Andit_Trail_Text_File , 

1 1  Subprograif.  "  £ 

Exception_Handler_Record.  Name  & 

"  is  not  authorized  to  handle  the  exception,  "  ) ; 
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TEXT_IO.  RJT_UNE  (  AuditJITail_Text_File,  "  ",  i 

Except i on_Name  &  "  raised  by  "  & 
Exception_Raiser_Record .  Name  ) ; 

end  if; 


end  Iog_Exception_in_Audit_Trail ; 


begin  —  Andit_Trail_hIanager_Package  initialization 

Mandatory_AooessjOontrol_Types_Package.  —  see  3  -  3.1.3 

Others_String (  1  ..  6  )  ;=  "others"; 

end  Andit_Prail_Mcinager_Package ; 


3.3  Assurance 

Assurance  of  the  correctness  of  a  TCB  system's  security  controls,  as  specified 
by  the  security  requirements,  determine  the  extent  that  the  security  architecture 
must  dictate  many  details  of  the  development  process.  The  two  types  of  assurance 
that  must  be  considered  are  operational  and  life-cycle. 


3.3.1  Operational  Assurance 

Operational  assurance  includes  the  following  aspects:  system  architecture,  system 
integrity,  covert  channel  analysis,  trusted  facility  management,  and  trusted 
recovery. 


3. 3. 1.1  System  Architecture 

The  TCB  must  maintain  a  domain  for  its  cwn  execution  that  protects  it  from 
external  interference  or  tampering.  It  must  maintain  process  isolation  through 
the  provision  of  distinct  address  spaces  under  its  control.  The  TCB  must  be 
internally  structured  into  well-defined  largely  independent  modules.  It  must 
make  effective  use  of  available  hardware  to  separate  those  elements  that  are 
protection-critical  from  those  that  are  not.  TCB  modules  must  be  designed  such 
that  the  principle  of  least  privilege  is  enforced.  Features  in  hardware,  such  as 
segmentation,  must  be  used  to  support  logically  distinct  storage  objects  with 
separate  attributes  (namely,  readable  and  writable) .  The  TCB  user  interface  must 
be  completely  defined  and  all  elements  of  the  TCB  must  be  identified.  The  TCB 
must  be  designed  and  structured  to  use  a  complete,  conceptually  simple  protection 
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mechanism  with  precisely  defined  semantics;  this  mechanism  must  play  a  central 
role  in  enforcing  the  internal  structuring  of  the  TCB  and  the  system.  The  TCB 
must  incorporate  significant  use  of  layering,  data  abstraction,  and  information 
hiding.  Significant  system  engineering  must  be  directed  toward  minimizing  the 
ocnplexity  of  the  TCB  and  excluding  from  the  TCB  modules  that  are  not  protection- 
critical. 

Guidelines  far  the  use  of  Ada  Constructs  and  Features: 

The  TCB's  system  architecture  must  be  modular,  and  use  data  abstraction  with 
information  hiding  in  its  implementation.  Ada  is  well  suited  to  incorporate 
modularity  with  its  packages  and  subprograms  and  to  implement  data 
abstraction  and  information  hiding  with  abstract  data  types  and  packages. 
To  ensure  system  integrity  and  to  prevent  the  creation  of  covert  channels, 
the  creation  of  TCB  system  features  (dynamic  storage,  input  and  output 
communications  within  the  TCB  and  between  the  user/subject  and  the  TCB, 
tasking  and/or  global  and  shared  variables)  must  address  the  potential 
security  problems  associated  with  their  implementation  and  use.  The 
recommended  constructs  and  their  discussion  in  Section  2.0  are  as  follows: 

ACCESS  TYPES  2  -  3.8 

INR7T  and  OUTPUT  2  -  14. 

PACKAGES  2-7. 

TYPES  2-3. 


3. 3. 1.2  System  Integrity 

Hardware  and/or  software  features  must  be  provided  that  can  be  used  to 
periodically  validate  the  correct  operation  of  the  on-site  hardware  and  firmware 
elements  of  the  TCB. 

Guidelines  for  the  use  of  Ada  Constructs  and  Features: 

Take  advantage  of  Ada  to  create  readable  code  that  helps  the  validation 
process.  See  the  discussion  of  identifiers  in  Section  2  -  2.3. 


3. 3. 1.3  Coverc  Channel  Analysis 

The  search  for  covert  channels  required  in  this  analysis  is  facilitated  by  having 
the  TCB  *  s  software  and  its  documentation  be  readable  and  understandable . 
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Guidelines  for  the  use  of  Ada  Constructs  and  Features: 

Take  advantage  of  Ada  to  create  readable  code  which  helps  the 
identification  of  covert  channels.  Refer  to  the  discussion  of  identifiers 
in  Section  2  -  2.3. 


3. 3. 1.4  Trusted  Facility  Management 

The  majority  of  issues  related  to  trusted  facility  management  are  not  software 
issues.  Rather,  they  are  concerned  with  the  responsibilities  of  the  security 
administrator  and  the  ADP  system  administrative  personnel. 

Guidelines  for  the  use  of  Ala  Constructs  and  Features: 

Take  advantage  of  Ada  to  create  readable  code  which  helps  the  management  of 
a  trusted  facility.  Refer  to  the  discussion  of  identifiers  in  Section  2- 
2.3. 


3. 3. 1.5  Trusted  Recovery 

Procedures  and/or  mechanisms  must  be  provided  to  assure  that  after  an  ADP  system 
failure  or  other  discontinuity,  recovery  without  a  protection  compromise  is 
obtained. 

Guidelines  for  the  use  of  Ada  Constructs  and  Features: 

Implement  trusted  recovery  with  Ada's  exception  handling  mechanism,  taking 
into  account  proper  security  considerations.  Refer  to  the  discussion  of 
exception  handling  in  Section  2-11.  System  reinitialization  and  backup 
should  be  handled  with  trusted  recovery  techniques.  This  requires  the  input 
and  output  operations  involved  in  system  reinitialization  and  backup  to  be 
trusted.  Refer  to  the  discussion  of  input  and  output  in  Section  2-14. 


3.3.2  Life-Cycle  Assurance 

Life-Cycle  assurance  includes  the  following  aspects:  security  testing,  design 
specification  and  verification,  and  configuration  management. 


3. 3. 2.1  Security  Testing 

Security  mechanisms  of  the  ADP  system  must  be  tested  and  found  to  work  as  claimed 
in  the  system  documentation.  A  team  of  individuals  who  thoroughly  understand  the 
specific  implementation  of  the  TCB  must  subject  its  design  documentation,  source 
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code,  and  object  code  to  thorough  analysis  and  testing.  The  team's  objective 
should  be  to  uncover  all  design  and  implementation  flaws  that  would  permit  a 
subject  external  to  the  TCB  to  read,  change,  or  delete  data  normally  denied  under 
the  mandatory  or  discretionary  security  policy.  This  will  assure  that  no  subject 
is  able  to  cause  the  TCB  to  enter  a  state  such  that  it  is  unable  to  respond  to 
communications  initiated  by  other  users.  The  TCB  must  be  found  resistant  to 
penetration.  All  discovered  flaws  must,  be  corrected,  and  the  TCB  roust  be 
retested  to  demonstrate  that  the  flaws  have  been  eliminated  and  that  new  flaws 
have  not  bean  introduced.  Testing  must  demonstrate  that  the  TCB  implementation 
is  consistent  with  the  descriptive  top-level  specification.  No  design  flaws  and 
no  more  than  a  few  correctable  implementation  flaws  may  be  found  during  testing 
and  there  must  be  reasonable  confidence  that  few  remain. 

Guidelines  for  the  use  of  Ada  Constructs  and  Features: 

Security  testing  of  the  TCB  system  is  promoted  by  having  the  system 
architecture  exhibit  modularity,  and  using  data  abstraction  with  information 
hiding  in  its  implementation.  Ada  is  well  suited  to  incorporate  modularity 
with  its  packages  and  subprograms  and  to  implement  data  abstraction  and 
information  hiding  with  abstract  data  types.  Security  testing  of  the  TCB 
system  must  include  the  testing  of  all  implementations  of  the  following 
system  features:  dynamic  storage  management,  input  and  output  communications 
within  the  TCB  and  between  the  user/subject  and  the  TCB,  tasking  and/or 
global  -and  shared  variables.  The  recommended  constructs  and  their 
discussion  in  Section  2.0  are  as  follows: 

INHJT  and  OTTFUT  2  -  14. 

PACKAGES  2-7 

SUBPROGRAMS  2-6. 

TYPES  2-3. 


3. 3. 2. 2  Design  Specification  and  Verification 

A  formal  model  of  the  security  policy  supported  by  the  TCB  must  oe  maintained 
that  is  proven  to  be  consistent  with  its  axioms.  A  descriptive  top-level 
specification  (DIIS)  of  the  TCB  must  be  maintained  that  completely  and  accurately 
describes  the  TCB  in  terms  of  exceptions,  error  messages,  and  effects.  It  must 
be  shewn  to  be  an  accurate  description  of  the  TCB  interface.  A  convincing 
argument  must  be  given  that  the  DTLS  is  consistent  with  the  model. 


3. 3. 2. 3  Configuration  Management 

A  configuration  management  system  must  be  in  place  that  maintains  control  of 
changes  to  the  descriptive  top-level  specification,  other  design  data, 
implementation  documentation,  source  code,  the  running  version  of  the  object 
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code,  and  test  fixtures  and  documentation.  The  configuration  management  system 
must  assure  a  consistent  mapping  among  all  documentation  and  code  associated  with 
the  current  version  of  the  TCB.  Tools  must  be  provided  for  generation  of  a  new 
version  of  the  TCB  from  source  code  and  for  ccnparing  a  newly  generated  version 
with  the  previous  TCB  version  in  order  to  ascertain  that  only  the  intended 
changes  have  been  made  in  the  code  that  will  actually  be  used  as  the  new  version 
of  the  TCB. 


3.4  Documentation 

Documentation  is  an  important  part  of  the  software  development  process.  It  aids 
users  who  are  not  familiar  with  the  system  in  learning  hew  to  vise  the  system 
correctly.  It  aids  support  programmers  in  testing  the  system  to  ensure  that  a 
modification  has  not  had  a  negative  impact  on  the  system.  This  is  especially 
important  when  developing  a  TCB,  because  the  security  of  the  system  is  of  the 
utmost  importance.  The  documentation  must  be  developed  to  meet  all  requirements 
set  forth  in  the  TCSEC,  and  must  be  complete  and  up  to  date. 

Guidelines  for  the  use  of  Ada  Constructs  and  Features: 

The  documentation,  particularly  the  design  documentation,  must  clearly 
convey  the  implementation  of  the  TCB  system  architecture,  which  must  exhibit 
modularity,  and  use  data  abstraction  with  information  hiding  in  its 
implementation.  Ada  is  well  suited  to  incorporate  modularity  with  its 
packages  and  subprograms  and  to  implement  data  abstraction  and  information 
hiding  with  abstract  data  types .  These  features  not  only  aid  the 
understandabil ity  of  the  code,  but  also  of  the  design  documentation.  The 
documentation  must  clearly  shew  hew  the  security  risks  are  handled, 
including  those  posed  by  the  following  TCB  system  features:  dynamic  storage 
management,  input  and  output  communications  within  the  TCB  and  between  the 
user/subject  and  the  TCB,  tasking  and/or  global  and  shared  variables,  and 
any  tailoring  or  configuring  of  the  Ada  compiler  or  runtime  system.  This 
discussion  of  the  application  of  Ada  constructs  to  documentation  applies  to 
the  following  four  subsections:  Security  Features  User's  Guide,  Trusted 
Facility  Manual,  Test  Documentation,  and  Design  Documentation. 

Ada  coding  conventions  should  use  Ada's  self-documenting  capabilities,  so 
that  the  code  can  contribute  to  the  design  and  testing  documentation.  The 
self-documenting  capabilities  can  be  realized  better  with  the  use  of  the 
following  conventions:  Readable  and  understandable  mnemonics  should  be  used. 

qqtIo  gHpni/9  ovh t v> vf*  ccnsistsTit  i  ixlsntSwion .  Blank  lines  should  used 
to  logically  partition  the  code.  Comments  should  be  inserted  into  the  code 
to  provide  information  that  is  not  conveyed  by  the  code.  Each  package  and 
subprogram  should  have  a  header  that  states  its  purpose,  its  authors,  and 
the  history  (dates)  of  its  creation  and  revision (s). 
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3.4.1  Security  Features  User's  Guide 

A  single  summary,  chapter,  or  manual  in  user  documentation  must  describe  the 
protection  mechanisms  provided  by  the  TCB,  guidelines  on  their  use,  and  hew  they 
interact  with  one  another. 


Guidelines  for  the  use  of  Ada  Constructs  and  Features: 

Ada  will  have  no  impact  on  the  development  of  the  Security  Features  User's 
Guide. 


3.4.2  Trusted  Facility  Manual 

A  manual  addressed  to  the  ADP  system  administrator  must  present  cautions  about 
functions  and  privileges  that  should  be  controlled  when  running  a  secure 
facility.  It  must  describe  the  operator  and  administrator  functions  related  to 
security,  to  include  changing  the  security  characteristics  of  a  user.  The  manual 
must  provide  guidelines  on  the  consistent  and  effective  use  of  the  protection 
features  of  the  system,  hew  they  interact,  hew  to  securely  generate  a  new  TCB, 
and  facility  procedures,  warnings,  and  privileges  that  need  to  be  controlled  in 
order  to  operate  the  facility  in  a  secure  manner.  TCB  modules  that  contain  the 
reference  validation  mechanism  must  be  identified.  Procedures  for  secure 
generation  of  a  new  TCB  from  source  after  modification  of  any  modules  in  the  TCB 
must  be  described.  The  manual  must  include  the  procedures  to  ensure  that  the 
system  is  initially  started  in  a  secure  manner.  Procedures  must  also  be  included 
to  resume  secure  system  operation  after  any  lapse  in  system  operation. 

Guidelines  for  the  use  of  Ada  Constructs  and  Features: 

Ada  will  have  no  inpact  on  the  development  of  the  Trusted  Facility  Manual. 


3.4.3  Test  Documentation 

The  system  developer  must  provide  to  the  evaluators  a  document  that  describes  the 
test  plan,  test  procedures  that  shew  has’  the  security  mechanisms  were  tested,  and 
results  of  the  security  mechanisms'  functional  testing.  Documentation  must 
include  results  of  testing  the  effectiveness  of  the  methods  used  to  reduce  covert 
channel  bandwidths. 

Guidelines  for  the  use  of  Ada  Constructs  and  Features: 

Ada  coding  should  be  self-documenting,  as  discussed  in  Section  3  -  3.4,  so 
that  it  can  contribute  to  the  testing  documentation. 
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3.4.4  Design  Documentation 

Documentation  must  be  available  that  provides  a  description  of  the  manufacturer's 
philosophy  of  protection  and  an  explanation  of  hew  this  philosophy  is  translated 
into  the  TCB.  The  interfaces  between  the  TCB  modules  must  be  described.  A 
formal  description  of  the  security  policy  model  enforced  by  the  TCB  must  be 
available  and  proven  that  is  sufficient  to  enforce  the  security  policy*  Specific 
TCB  protection  mechanisms  must  be  identified,  and  an  explanation  must  be  given  to 
show  that  they  satisfy  the  model.  The  TCB  implementation  (i.e. ,  in  hardware, 
firmware,  and  software)  must  be  shown,  using  informal  techniques,  to  be 
consistent  with  the  DUS.  The  elements  of  the  DUS  must  be  shewn,  using  informal 
techniques,  to  correspond  to  the  elements  of  the  TCB.  Documentation  must 
describe  hew  the  TCB  implements  the  reference  monitor  concept  and  give  an 
explanation  why  it  is  tamper  resistant,  cannot  be  bypassed,  and  is  correctly 
implemented.  Documentation  must  describe  how  the  TCB  is  structured  to  facilitate 
testing  and  to  enforce  least  privilege.  Documentation  must  also  present  the 
results  of  covert  channel  analysis  and  the  tradeoffs  involved  in  restricting  the 
channels.  All  auditable  events  that  may  be  used  in  the  exploitation  of  known 
covert  storage  channels  must  be  identified.  The  bandwidths  of  known  covert 
storage  channels,  the  use  of  which  is  not  detectable  by  the  auditing  mechanisms;, 
must  be  provided. 


Guidelines  for  the  use  of  Ada  Constructs  and  Features: 

Ada  code  should  be  self-documenting,  as  discussed  in  Section  3.4,  so  that  it 
can  contribute  to  the  design  documentation.  The  use  of  Ada  PDL  will  assist 
in  generating  readable  and  understandable  design  documentation . 
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4.0  SUMMARY  AND  CONCLUSIONS 
4.1  SUMMARY 

This  appendix  is  a  set  of  guidelines  on  how  to  use  Ada  in  the  development  of 
TCBs.  These  include  guidance  on  how  to  exploit  the  advantages  of  using  Ada,  such 
as  data  abstraction,  information  hiding,  modularity,  localization,  strong  data 
typing,  packages,  subprograms,  and  tasks.  They  also  provide  guidance  on  hew  to 
avoid  problems  with  using  Ada,  which  are  associated  with  certain  Ada  constructs 
and'  features. 

Sections  2.0  and  3.0  address  the  guidelines  in  two  ways.  First,  Section  2.0 
provides  definitions  of  and  general  programming  guidelines  on  the  use  of  Ada 
constructs  and  features  mapped  directly  to  the  IfM.  Section  3.0  provides 
guidelines  on  the  application  of  Ada  constructs  and  features  in  the  context  of  a 
mapping  of  Ada  usage  to  generalized  TCB  criteria.  In  particular,  Class  B3  is 
used  as  a  template  for  the  generalized  TCB  criteria. 

Those  guidelines  specific  to  both  TCB  development  and  Ada  are  presented  here.  A 
developer  should  be  experienced  with  the  TCB  development  process  and  have 
established  guidelines  for  the  development  of  TCBs.  Also,  a  developer  should  use 
general-purpose  Ada  guidelines.  The  guidelines  presented  here  are  meant  to 
complement  both  TCB  development  guidelines  and  general-purpose  Ada  guidelines. 


4.2  CONCLUSIONS 

Because  Ada  was  designed  with  features  and  constructs  that  promote  recognized 
sound  software  engineering  principles,  it  is  well  suited  as  the  implementation 
language  of  TCBs.  Ada  offers  various  specific  benefits  for  the  development  of 
TCBs,  such  as  the  capability  of  creating  TCB  systems  that  exhibit  modularity  and 
information  hiding  with  the  use  of  packages.  These  guidelines  are  meant  to 
enable  developers  to  realize  these  benefits.  Also,  certain  Ada  constructs 
provide  both  advantages  and  disadvantages.  In  tnese  cases  the  guidelines  are 
meant  to  enable  developers  to  realize  the  advantages  of  a  construct  while 
minimizing  or  elimirating  its  disadvantages. 
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5.0  CDHECTICN  OF  EXAMPLES 

The  following  examples  have  been  cxillected  from  Sections  2.0  and  3.0  to 
provide  a  single  area  for  referencing  them.  The  section  naming  conventions 
"2  and  "3  have  been  retained  for  consistency  and  ease  of  reference  to 
the  preceding  sections. 

2-2.  Lexical  Elements 

Examples:  This  example  illustrates  underscoring  in  numeric  literals,  which 
improves  the  readability  of  literals  that  have  many  digits. 
Underscores  are  used  in  place  of  commas  in  large  numbers.  In 
strings  of  digits  to  the  right  of  the  decimal,  an  underscore  is 
used,  for  example,  after  every  fifth  digit. 

123_456  rather  than  123456  —  integer  literal 

3.14159  26  rather  than  3.1415926  —  real  literal 


2  -  2.4.2  Based  Literals 

Examples:  This  example  illustrates  base  literals. 

—  integer  literals  of  value  255 
2  7-1111  1111#  16#FF#  016#0FF# 


2  -  2.3  Identifiers 


Examples:  The  following  examples  illustrate  clearly  readable  and 

understandable  mnemonic  identifier  names.  They  are  identifiers 
which  are  used  in  later  examples  in  this  appendix.  The  use  of 
each  identifier  should  be  clear  based  on  its  name.  This  set  of 
identifiers  is  taken  out  of  context;  thus  they  do  not  constitute 
compilable  code. 


NamedjOb  j  ect_ACL_Record  —  see  2 
Max_Named_String_Length  —  see  2 
Named_Individual  s_Iist_Type  —  see  2 
Scrubbed_Named_Objects_List  —  see  2 


3.2.1 

3.2.2 
3.2.1 
3.2.1 
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2  -  3.2.1  Object  Declarations 

Examples:  The  following  examples  illustrate  clearly  readable  and 

understandable  mnemonic  object  declarations.  This  set  of  object 
declarations  include  the  initialization  of  the  objects. 

—  Max_Named_String_Iength,  Name_String_Type ,  and  Blank_Name_String 

—  are  declared  in  package  Bas  ic_TCB_Types_Package .  Because  only  essential 

—  features  of  this  package  need  to  be  shewn,  it  is  not  included  formally  in 

—  this  appendix. 

Blank_Name_String  :  Name_String_Type  —  see  2  -  3.6.3 

:=(!..  Max_Named_String_Length  =>'');  —  see  2  -  3.2.2 


The  next  three  declarations  in  this  section  are  located  in  the  array 
types  version  of  package  Access_Control_List_Types_Package .  Because  only 
essential  features  of  this  package  need  to  be  shown,  it  is  not  included 
formally  in  this  appendix. 


Scrubbed_Naitved_Ob  j  ects__List  : 

NamedjDbj  ects_List_Type 
Named_Ob j ects_Ldst_Type ' 

(  others  =>  BasicJICB_Types_Package . 

Blank_Name_String  ) ; 

Scrubbed_Named_Individuals_List  : 

Named_Individual  s_List_Type 
:=  Named_Individuals_List_Type' 

(  others  =>  Bas ic_TCB_Types_Package . 

Blank_Name_String  ) ; 

Scrubbed_Groups_of_Named_Individuals_List  : 

Groups_of_Named_Individuals_Ldst_Type 
:  =  Groups_of_Named_Individuals_List_iype ' 
(  others  =>  Bas ic_TCB_Types_Package . 

Blank_Name_String  ) ; 


—  see  2  -  3.6 


—  see  2  -  3.6 


—  see  2  -  3.6 


The  next  three  declarations  in  this  section  are  located  in  the  access 
types  version  of  package  Access_Control_List_Types_Package.  Because  only 
essential  features  of  this  package  need  to  be  shewn,  it  is  not  included 
formally  in  this  appendix. 
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Scrubbea_Named_Ob j  ects_List  : 

NamedjOb j  ects_List_Type  —  see  2-3.8 

:=  Named_Ob j  ects_List_Type ' 

(  Name  =>  Basic_TCB_Types_Package . 

Blank_Name_String , 

Next  =>  null  ) ; 

Scrubbed_NamedJEndividual  s_List  : 

NamedJtndividualsJListJiype  —  see  2-3.8 

:=  Naii^_IrK±Lviduals_ListJTy^ * 

(  Name  ->  Basic_TCB_Types_Package . 

Blank_Name_String , 

Next  =>  null  ) ; 


Scrubbedj3roupsjof_Named_Individuals_List  : 

GrrKjps_of_NaiT^_Individuals_List_Type  —  see  2  -  3.8 

:=  Groups_cf_Named_Individuals_List_Type ' 

(  Name  =>  Bao  ic  JICB_Types_Package . 

Blank_Name_String , 

Next  =>  null  ) ; 

The  remaining  declarations  in  this  section  are  located 
in  both  the  access  and  array  types  versions  of 

package  Access_Oontrol_ListJTypes_Package.  Because  only  essential 
features  of  this  package  need  to  be  shewn,  it  is  not  included  formally  in 
this  appendix. 

Scrubbed JtemedjObj  ect_ACL_Record  : 

Named_Object_Record_iype  —  see  2-3.7 

:=  NamedjQbject_Record_Type' 

(  Name  =>  Basic_TCB_Types_Package. 

Blarik_Name_String , 

Sensitivity_Label  => 

Mandatory_Access_Control_Types_Package . 

Scrubbed_Sensitivity_Label ,  —  see  3  -  3.1.3 

Authorized_Named_Individuals_List  => 
ScrubbedJ^amed_Individuals_List , 

Author i z ed_Groups_of_Named_Individual  s_List  => 
ScrubbedjSroups_of_Named_3hdividuals_List , 

Unauthorized_Named_Individuals_List  => 

Scrubbed  Named_Individuals_List  ) ; 
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Named_Ob j  ect_ACL_Record  :  NamedjOb j  ec±._RecordJiype  —  see  2-3.7 
:=  Scrubbed_Named_Ob  j  ect_ACL_Record ; 


Scrufcbed_Named_lndividual_ACL_Record  : 

Named_Individual_Record_Type  —  see  2-3.7 

:=  Named JEndividualJlecord_Type ' 

(  Items  ~>  Bsisic_TCB_Types_Package . 

BlankJtemejString , 

—  see  2  -  3.6.3 

Sensitivity_Label  => 
hterxtetory_Acc(iss_Control_Types_Package . 

Scrubbed jSens  it  ivityJLabel ,  —  see  3  -  3.1.3 

Named_Ob  j  ects_List  =>  Scrubbed_NaixedjObjectsJList  )  ; 


NamedJDxIividual_ACLJtecord  : 

Named_Irriividual_RecordJType  —  see  2-3.7 

:=  Scrubbed J^amed_Irdividual_ACLJlec»rd  ; 


Sc3rubbedj3roip_of_Nanved_]^idividuals_ACL_Record  : 
Groupjaf_Named_Individuals_RecordJType  —  see  2-3.7 

:=  Group jDf_Named_IrriividualsJRecordJType ' 

(  Name  =>  Bcisic_TCB_Types_Package . 

BlankJtemejString, 

—  see  2  -  3.6.3 

Sensitivity_Label  => 

Mandatory_Access_ControlJIVpes_Package . 

Scrubbed JtensitivityJLabel,  —  see  3  -  3.1.3 

Named jDbjects_List  =>  ScrubfoedJtemedjOb j  ects JList  ) ; 


GruupjofJtemedJDxiividualsJ£LJReoord  : 
Group_of_Naired_Individuals_Record_Type  — 

:=  Scrubbed  Group  of  Named  Individuals  ACL  Record; 


see  2  - 
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2  -  3.2.2  Number  Declarations 

Example:  The  following  example  illustrates  a  clearly  readable  and 
understandable  mnemonic  number  declaration 

—  MaxJJamedjStringJLength  is  declared  in  package  BasicJKB_Types_Package . 

—  Because  only  essential  features  of  this  package  need  to  be  shewn,  it  is 

—  not  included  formally  in  this  appendix. 

Max_Named_String_Length  :  constant  :=  80; 


2  -  3.3.1  Type  Declarations 

Example:  Ihe  following  example  illustrates  a  clearly  readable  and 
understandable  mnemonic  type  declaration. 

DayJType  is  declared  in  package  Basic_Types_Package .  Because  only 

—  essential  features  of  this  package  need  to  be  shewn,  it  is  not  included 

—  formally  in  this  appendix. 

type  DayJType  is  (  Sunday,  Monday,  Tuesday,  Wednesday, 

Thursday,  Friday;  Saturday  ) ; 


2  -  3.3.2  Subtype  Declarations 

Example:  The  following  example  illustrates  a  clearly  readable  and 
understandable  mnemonic  subtype  declaration. 

Weekday Jtype  is  declared  in  package  Basic jTypesJPackage.  Because  only 
essential  features  of  this  package  need  to  be  shown,  it  is  not  included 
formally  in  this  appendix. 

subtype  WeekdayJType  is  DayJType  range  Monday  . .  Friday; 


2  -  3.4  Derived  Types 

Example:  The  following  example  illustrates  a  clearly  readable  and 
understandable  mnemonic  derived  type  declaration.  The 
package  Key_Manager_Package  is  declared  in  section  2  -  7.4.2. 
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type  Access__Key_Type  is  new  Rey_Manager_Package .  Key_Type ; 

—  the  derived  subprograms  have  the  following  specifications: 

—  procedure  Get_Key  (  K  :  out  Access_Key_Type  ) ; 

—  function  "<"  (  X,  Y  :  Access_Key_Type  )  return  BOOLEAN; 

—  function  "+"  (  X,  Y  :  Access_Key_iype  )  return  Access_Key_Type ; 


2  -  3.5.1  Enumeration  Types 

Example:  The  following  example  illustrates  a  clearly  readable  and 
understandable  mnemonic  enumeration  type  declaration. 

—  Security_Classification_Type  is  declared  in 

—  package  BasicJTCB_Types_Package .  Because  only  essential 

—  features  of  this  package  need  to  be  shewn,  it  is  not  included 

—  formally  in  this  appendix. 

type  Security_Classification_Type  is 

(  Unclassified,  Confidential,  Secret,  TcpjSecret  )  ? 


2  -  3.6  Array  Types 

Exanples:  The  following  examples  illustrate  clearly  readable  and 
understandable  mnemonic  array  type  declarations. 

—  The  following  declarations  in  this  section  are  located  in  the  array 

—  types  version  of  package  Access j2ontrolJListJTypes_Package.  Because  only 

—  essentia],  features  of  this  package  need  to  be  shown,  it  is  not  included 

—  formally  in  this  appendix. 

Max_Numbex*_of_Objects  :  constant  NATURAL  :=  25; 

Max_Number_of_Irdividuals  :  constant  NATURAL  :=  25; 

MaxJtorriber_of_Groips_of_Individuals  :  constant  NATURAL  :=  25; 


type  Named jObjects_List_Type  is  array 

(  POSITIVE  range  1  ..  Max_Number_of_Ob j  ects  )  of 
Basi  c_TCE_Types_Package .  Name_of_Object_Type;  —  see  2-4.1 

type  NamedjOb j  ects_ACL_Type  is  array 

(  POSITIVE  range  1  ..  Max_Nuniber_of_Objects  )  of 
NamedjOb j ect_Record_Type ;  —  see  2  -  3.2.1 
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type  NamedJLndividuals_lJst_Type  is  array 

(  POSITIVE  range  1  ..  Max_Nuni)er_of_Individuals  )  of 
Bas ic_TCB_Types_Package . 

Name_of_Individual_Type ;  —  see  2-4.1 

type  Named_IndividualsJ^CLJiype  is  array 

(  POSITIVE  range  1  ..  Max_Number_o  f_Individual  s  )  of 
Named_Individual_Recx3rxi_Type;  —  see  2  -  3.2.1 


type  Groups_of_Named_Individuals_List_Type  is  array 

(  POSITIVE  range  1  ..  Max_Nurnber_of_Gr«ps_of_Indi.vidual s  )  of 
Bas ic_TCB_Types_Package . 

Name_of  j3ro<ip_of_Individuals_Type ;  —  see  2-4.1 

type  Grc^psjofJNaited_Individuals_ACLJiype  is  array 

(  POSITIVE  range  1  ..  MaxJAirttoerjofjGroips_of_Individuals  )  of 
Group_of_Named_Individuals_Record_Type ;  —  see  2  -  3.2.1 


2  -  3.6.3  The  Type  String 

Example:  The  following  example  illustrates  a  clearly  readable  and 
understandable  mnemonic  string  type  declaration. 

Name_String_Type  is  declared  in  package  BasicJTCB_Types_Package . 
Because  only  essential  features  of  this  package  need  to  be  shown, 

—  it  is  not  included  formally  in  this  appendix. 

subtype  Name_StringJType  is 

•STRING  (  1  ..  Max_Nan^_Strir>g_]j2ngth  );  —  see  2  -  3.2.2 


2  -  3.7  Record  Types 

Examples:  The  following  examples  illustrate  clearly  readable  and 
understandable  mnemonic  record  type  declarations. 

—  The  foilwing  declarations  in  this  section  are  located  in  both  the  access 

—  and  array  types  versions  of  package  Access_Control_List_Types_Package. 

—  Because  only  essential  features  of  this  package  need  to  be  shewn,  it  is 

—  not  included  formally  in  this  appendix. 
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type  Named_Ob j  ect_Record_Type  is 
record 

Name  :  Bas  icJKBjrypes_Package .  Name_of_Cb j  ectjiype  —  see  2  - 
:=  BasicJIX3!JIVpes_Package.  Blank_Naxne_Strir>gf  —  see  2-3, 

SensitivityJLabel  : 

Marriatory~AcxxssJ2}rrtrolJI^^ . 

SensitivityJLabelJType 

Mandat»ry_Acx«ss_C^jtrolJIVpes_Package. 

Scrul±^d_Serisitivity_Label ;  —  see  3  -  3.1.3 

Authorized Jtoirad_Individuals_Li3t  : 

2^amed_IMivic^ls_lJLSrtJIVpe  —  see  2  -  3.6  and  2  -  3.8 

:=  Gcrubbed_Named_Individuals_Ijist ?  —  see  2  -  3.2.1 

Authorizedj3nxps_cf_Named_lndividuals_List  : 

—  see  2  -  3.6  and  2  -  3.8 
Graups_ofJ^amed_Ir)dividuals_List_Type 
Sc^ubbed_Gro,jp>sjof_Nan«d_Individuals_List ;  —  see  2  -  3.2.1 

Umuthorized_Nait^_Individuals__List  : 

Naiied~Individuals_List_Type  —  see  2-3.6  and  2-3.8 
;=  Sc^a^}Ded_Named_Irdividuals_Ijist ;  •  —  see  2  -  3.2.1 

end  record; 


type  Nairol_Irdividual_Rec«rd_Type  is 
record 

Name  :  BasicJTCB_Types_Package . 

Naitie_of_]3dividualJiype  —  see  2-4.1 

:=  Basic JTCBJTypesJPackage .  Blank_Name_String;  —  see  2  -  3.2.1 

Sensitivity_Label  : 

Mandatory_Acxess_Control_Types_Package . 

Sensitivity_Label_Type 

:=  N^datory_Aocess_Control_Types_Pac}cage . 

Scrubbed_SeraitivityJLabel ;  —  see  3  -  3.1.3 

Named_Ob  j  ects_List  : 

Named_Ob  j ects_List_Type  —  see  2  -  3.6  and  2  -  3.8 

;=  Sctn;ibbed_Named_Ob j ectsJList ;  —  see  2  -  3.2.1 

end  record; 
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type  Group_of_Named_Individuals_Record_'iype  is 

record 

Name  :  BasicJTCBJiypesJPackage. 

Namejofj3rtup_of_Irxlividualsjrype  —  see  2-4.1 

:=  Basic _TCB_Types_Package.  Blank_Name_String ;  —  see  2  -  3.2.1 


Sensitivity_Iabel  : 

Mandatory_Aocess_Oontro3  _Types  JPackage . 

Sens  it  ivity_Label  Jiype 

:=  Mandatory_Access_Control_Types_Package . 

Scrubbed_Sensitivity_Label;  —  see  3  -  3.1.3 


Named_Ctojects_List  : 

Named_Qb j ects_ListJiype  —  see  2  -  3.6  and  2  -  3.8 

:=  Scrubbed_Named_Ob  j ects_List ;  —  see  2  -  3.2.1 

end  record; 


2  -  3.8  Access  Types 

Examples:  The  following  examples  illustrate  clearly  readable  and 

understandable  mnemonic  access  type  declarations.  To  ensure  that 
the  memory  allocated  to  a  node  is  scrubbed,  the  components  of  a 
node's  record  type  should  be  initialized  to  scrubbed  values,  as 
shown  below.  Also,  ensure  that  a  node  record  is  set  to  scrubbed 
values  before  it  is  placed  back  in  the  heap,  i.e.,  befc_3  nothing 
points  to  it  any  longer. 


The  following  declarations  in  this  section  are  located  in  the  access 
types  version  of  package  Access_Control_List_Types_Package .  Because  only 
essential  features  of  this  package  need  to  be  shown,  it  is  not  included 
formally  in  this  appendix. 


type  Named_Objects_List_iype; 
type  NamedjC&jects_Iist_Pointer_Type 
is  access  Named_Ob j  ects_List_Type ; 

type  Named_Objects_List_Type  is 
record 

Name  :  Bas ic_TCB_Types_Package . 

nwuir..  \/i.  ijlAL. 

:=  Bai;icJTCB_Types_Packac'e. 

Blank_Nanie_3tring  ; 

Next  :  NamedjOb  j ects_List_Pointer_Type  :=  null; 
«id  record; 


sec  2  -  4.3. 
see  2  -  3.2.1 
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type  Namad_Ob j  eots_ACL_Type ; 
type  NamedjOb j  eots_ACL_Pointer_Type 
is  access  NamedjOb j  ec±s_ACL_Type ; 

type  NamedjOb  j  ects_ACL_Type  is 
record 

NamedjOb  j ect_ACL_Reoord  : 

Named job j  ect JReoord Mtype 

:=  Scrubbed_Named_Ob j ect_ACL_Record ;  —  see  2  -  3.2.1 

Next  :  NamedjOb  j  ects_ACLJFbirrterJType 
:=  mill ; 
end  record; 


type  Named_Individuals_ListJiype 
type  Named_Irdividuals_List_Pointer_Type 
is  access  Named_Individual  s_List_Type ; 

type.  Nait^_In±Lviduals_Listjrype  is 
record 

Name  :  Basic  JTCBJTypesjPackage . 

Name_of_IndividualJiype  —  see  2-4.1 

;=  BasicJTCBJTypes_Package . 

Blank_Name_String;  —  see  2  -  3.2.1 

Next  :  Named_Individuals_List_Pointer_Type  :=  null; 
end  record; 


type  Named_Iirlividuals_ACLJiype ; 
type  Named_]jndividuals_ACL_Pointer_'iype 
is  aooess  NamedJEndividuals_ACl,jrype; 

type  Named_Individuals_ACL_'iype  is 
record 

Named_Individual_ACL_Record  : 

Named_Individual_Record_'iype 

:=  Scrubbed_Named_Individual_ACL_Record ;  —  see  2  -  3.2.1 

Next  ;  Named  Individuals  ACL  Pointer  iyps 
:=  null; 
end  record; 
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type  Groups_of_Naroed_Iniividuals_Liist_Type 
type  Groups_of_Named_Individuals_List_Pointer_Type 
is  access  Grrxjps_of_Named_]hdividU2ds_List_Type  ; 

type  Grtx^_of_Named_Individuals_List_Type  is 
record 

Name  :  Basic JTCB_Types_Package . 

Name_of_Grxx3p__of_Individuals_Type ;  —  see  2-4.1 

:=  BasicJICBJiypesJFackage. 

Blank_Name_String;  —  see  2  -  3.2.1 

Next  :  Gra^_of  J4amed_Irdividucils_ListJPoint^_'iype 
:=  null; 
end  record; 


type  Grt>ups_of_NaiTved_Individuals_ACL_Type ; 
type  Groups_cf_NamBd JIhdividual  s_ACL_Pointer_Type 
is  access  Groipsjof_NeffledJDidividuals_ACLjrype; 

type  Gro^_ofJ^aired_Ijidivictaals_ACL_Type  is 
record 

Group_of  J^amed_Irdividuals_ACL_Record  : 
Group_of_Naired_Individuals_RecordJiype 
;=  ScxuhbedjSrxx^jof_Named_Individuals_ACL_Record; 

—  see  2  -  3.2.1 

Next  :  Groups_of_NamedJIndividuals_ACL_PointerJiype 
:=  null; 
end  record; 


2  -  4.1  Names 

Exanples:  The  following  examples  illustrate  clearly  readable  and 
understandable  mnemonic  names. 

—  The  following  type  declarations  in  this  section  are  located  in 

—  package  Bas ic_TCB_Types_Package .  Because  only  essential  features  of  this 

—  package  need  to  be  shewn,  it  is  not  included  formally  in  this  appendix. 

subtype  Name_of  job j ect_Type  is  Name_String_Type ;  —  see  2  -  3.2.2 

Name_of_Object  :  Name_of_Ob j  ect_Type 

Blank_Name_String;  —  see  2  -  3.2.1 


C-126 


APPENDIX  C 

Collection  of  Examples 


subtype  Name_of_Indiviaual_Type  is  Name_String_Type ;  —  see  2  -  3.2.2 

Name__of_Individual  :  Name_of_Individual_Type 

:=  Blank_Naine_String ;  —  see  2  -  3.2.1 

subtype  Naire_of_Group_of_Individuals_Type  is  Name_String_Type ; 

—  see  2  -  3.2.2 

Name_ofj3rtx^_of_Nained_Individuals  : 

NamejDf_Group_of_IndividualsJiype 

:=  Blank_Name_String;  —  see  2  -  3.2.1 


2  -  6.4.2  Default  Parameters 

Example:  This  example  illustrates  named  parameter  association. 

procedure  Search_File  (  File  :  in  out 

Access_Control_List_Types_Package . 
ACL_File_Type ; 

Key  :  in  Name; 

Index  :  out  FileJEndex  ) ; 

SearchJFile  (  File  =>  ACL_File, 

Key  =>  "Smith  ,  J", 

Index  =>  Record JEhtry  ) ; 


Example:  Ihis  example  from  package  TEXTJEO  illustrates  default  parameters. 

procedure  CREATE  (  FILE  :  in  out  FILEJIYPE; 

MODE  :  in  FILEJMODE 

NAME  :  in  STRING 

FORM  :  in  STRING 

TEXT_IO.  CREATE  (  FILE  => 

NamedjObj  ects_Access_Control_List_Manager_Package . 

ACL_File  ) ; 


2  -  7.2  Package  Specifications  and  Declarations 

Example:  This  example  illustrates  data  abstraction  and  information  hiding, 
modularity,  and  localization  achieved  with  package  specification 
and  declarations. 


=  OOTJFTLE; 

—  fill  . 

t 

—  lift  \  . 
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with  Basic_TCB_Types_Package ; 

with  Access_Control_List_Types_Package ; 

package  Named_Ob j  ects_Access_Control_List_Manager_Package  is 


procedure  Get_Named_Ob j  ect_ACL_Record 

(  Name_of_Ob j  ect  :  in  Bas ic_TCB_Types_Package . 

Name_of_Ob j ect_Type ;  —  see  2  -  4.1 

Named_Ob j  ect_ACL_Pv2Cord  :  cut 
Access_Control_List_Types_Package . 

Named_Qb  j  ect_Record_Type  ) ;  —  see  2-4.1 

procedure  Insert_Named_Ob j  ect_ACL_Record 
(  NamedjOb j  ect_ACL_Pecord  :  in 

Access_Control_List_Types_Package . 

NamedjOb  j ect_Record_Type  ) ;  —  see  2  -  4.1 

procedure  Delete_Named_Ob  j  ect_ACL_Record 

(  Name_of_Object  :  in  BasicJTCB_Types_Package . 

Name_of_Ob j  ect _Type  ) ;  —  see  2  -  4.1 


Overflcw_Access_Control_List  :  exception; 
Access_Control_List_is_Nul 1  :  exception; 

private 


end  Named_Ob j  ects_Access_Control_List_Manager_Package ; 


package  body  Naroed_Ctojects_Access_Control_List_Manager_Package  is 


By  declaring  the  NamedjOb  j  ects_ACL  (see  2  -  12.4)  in  the 
body  of  this  package  rather  than  in  the  specification, 
it  is  hidden  from  the  user  of  this  package.  Thus,  the  user 
can  gain  only  indirect  access  to  it  through  the  subprograms 
declared  in  the  specification.  The  typical  list  manipulation 


u^cisi.iud 


(  £-9* 


Ml’ 


Feldman  1985  )  are  only  provided  in  the  package  body. 
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—  Typical  list  manipulation  operations 


procedure  Get_Named_Ob j  ect_ACL_Record 

(  Name_of_Ob j  ect  :  in  Basic_TCB_Types_Package . 

Name_cf_Cb j  ect_Type ;  —  see  2-4.1 

Named_Ob j  ect_ACL_Record  :  out 
Access j2ontrol_Ld£t_Types_Package . 

Named_Ob j  ect_Record_Type  )  is  —  see  2-4.1 


begin  —  Get_Named_Ob j  ect_ACL_Record 


—  Sequence  through  the  Named_Object_ACL  using  the  typical 

—  list  manipulation  operations  to  locate  and  get  the 

—  indicated  Named_Ob j  ect_ACL_Rficord . 


*  •  • 

end  Get_Named_Ob j  ect_ACL_Record ; 

procedure  Insert_Named_Ob j  ect_ACL_Record 
(  Named_Ob j  ect_ACL_Record  :  in 

Access_Control_List_Tvpes_PacXage . 

NamedjOb  j  ect_Record_Type  )  is  —  see  2-4.1 


begin  —  Insert_Named_Object_ACL_Record 


Sequence  through  the  Nairad_ob j ect_ACL  using  the  typical 
list  manipulation  operations  to  locate  the  appropriate 
place  to  insert  the  indicated  NamedjOb  j  ect_ACL_Record . 
This  location  is  determined  by  a  predefined  mechanism, 
e.g.,  a_phabitizing  by  the  Named_Object_ACL_Record.Name, 


XJJ  Cl 


/  T7TtVh\ 

\  i  -Li  Vy  O  UlUV  U1 


fVTT  r\\ 
Vxxi-^; 


end  Insert_Named_Ob j  ect_ACLJRecord  ; 
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procedure  Delete_Named_Qbj  ect_ACL_Record 

(  Name_of_Ob j ect  :  in  BasicjrcB_Types_Package. 

NairejofjObjectJType  )  is  —  see  2-4.1 


begin  —  Delete_Named_Ob j  ect_ACL_Record 


—  Sequence  through  the  Named_Object_ACL  using  the  typical 

—  list  manipulation  operations  to  locate,  scrub,  and  delete 

—  the  indicated  NamedjOb j  ect_ACL_Record . 


end  Delete_NamedjObject_ACL_Record; 


end  Named_Cfcjects_Access_Control_List_Manager_Package  ; 


2  -  7.4.2  Operations  of  a  Private  Type 

Exanple:  The  abstract  data  type,  Key_Type,  is  created  with  the  use  of 

the  package  Key_Manager_Package  and  its  private  type,  Key_Type . 

package  Key_Manager_Package  is 
type  Key_Type  is  private; 

NullJKey  :  constant  Key_Type; 
procedure  Get_Key  (  K  :  out  Keyjiype  ) ; 
functio:.  "<"  (  X,  Y  :  Key_Typs  )  return  BOOLEAN; 
function  "+"  (  X,  Y  ;  Keyjiype  )  return  Keyjiype; 

private 

type  Keyjiype  is  new  NATURAL; 

Null_Key  ;  constant  Keyjiype  ;=  0; 
end  Key_Manager_Package; 
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package  body  Key_Manager_Package  is 

Last_Key  :  Keyjiype  :=  0; 

procedure  Get_Key  (  K  :  out  Keyjiype  )  is 
begin 

Last_Key  :=  Last_Key  +  1; 

K  :=  Last_Key; 
end  Get_Key; 

function  "<"  (  X,  Y  :  ReyJType  )  return  0OOIEAN  is 
begin 

return  NATORAL  (  X  )  <  NATURAL  (  Y  ) ; 
end  ; 

function  "+"  (  X,  Y  :  Keyjiype  )  return  Keyjiype  is 
begin 

return  Keyjiype  (  NATURAL  (  X  )  +  NATORAL  (  Y  )  )  ; 

end 

end  Key_Manager_Package; 


2  -  9.2  Task  Types  and  Task  Objects 

Example:  This  example  illustrates  trusted  generalized  mechanisms  to 

control  and  regulate  intertask  communications  with  semaphores. 

with  Mandatory_Access_Control_Types_Package; 
with  Mandatory_Access_Control_Manager_Package; 
with  AuditJTrail J«5anager_Package ; 
generic 

I>lax_Number_o f _Tasks_Al  1  cwed  :  in  NATURAL  :=  1; 

package  GenericjCounting_SemaphoreJ’ianager_Package  is 

task  type  Count  ing_SerraphoreJTask  JType  is 
entry  Allcwjrask_to_Pass  ( 

Other JJ?ask_MAC_Record  :  in 
Mandatory_Access_Control Jiypes_Package . 

^  *****  \  ~  coh  3  —  3.1.3 


—  see  3  -  3.1.3 

—  see  3  -  3.1.3 

—  see  3  -  3.2.3 
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entry  Release_Task  ( 

Other_Task_MAC_Record  :  in 
Mamatory_Access_Ccrrtrol_Types_Package . 

MAC_Record_Type  ) ;  —  see  3-3. 

end  Ccuntirg_Seriaphore_Task_'IVpe  ; 


end  Generic_Counting_Senaphore_Mai-ager_Package  ? 


package  tody  Geroricj03unting_Semaphore_Manager_Package  is 
task  body  Countir>g_SeraphoreJIdsk_Type  is 

Number  of  Tasks  :  INTEGER  :=  Max  Number  of  Tasks  Allowed; 


Local_MAC_Record  : 

Mandatory J^cx3essj3ontjrolJiypes_Package . 
MAC_Record_Type ; 

Other_Task_MAC_Record  : 
Mandatory_Access_COntrol_Types_Package . 
MAC_Record_Type ; 


see  3-3. 


—  see  3-3. 


begin  —  Counting_SeiraphoreJTaskJiype 
loop 
select 

when  Number_of_Tasks  >  0  => 
accept  Allcw_Task_to_Pass  ( 

Other_Task_MAC_Record  :  in 

Mandatory_Access j3ontrolJiypes_Package . 
MACJRecord_Type  )  do  —  see  3-3. 

if  Mandatory_Access_ControlJ‘lanager_Package. 

Sensitivity_Labels_Match  —  see  3-3. 

(  Local_MAC_Reoord.  Sensitivity_label , 
Other_Task_KAC_Record . 

Sens  itivity_Label  )  then 

Ai>dit_Tra.il_Manager_Package.  —  see  3-3. 

Log_Subj  ects_Access_to_Ob j  ect_in_Audit_Trail  ( 
Local  MAC  Record,  Other  Task  MAC  Record  ) ; 
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Number_of_Tasks  :=  Number_of_Tasks  -  1; 
aid  if; 

end  Mlw_Task_to_Pass ; 


when  Number_of_Tasks  <  Max_Number_of_Tasks_Allcwed 
=>  accept  ReleaseJTask  ( 

Other_Task_MAC_Record  :  in 

M2uidatory_Aa3essjCiantTOl JIVpes_Paclcage . 
MAC_Record_Type  )  do  • —  sec  3  -  3.1.3 

if  Mardatory_Ac*3essj0caTtxol_Mamger_Pacdcage. 

Sens itivity_Labels_Match  —  see  3  -  3.1.3 

(  Iocal_MAC_Record .  SensitivityJLabel, 

Other JiaskJ4ACJtecord . 

SensitivityJLabel  )  then 

Audit Jirail_Manager_Package.  —  see  3  -  3.2.3 

Log_Sub j  ects_Acxess_tq_Cfo j  ect_in_Audit_Trail  ( 
Local_MAC_Record ,  OtherJiaskJWJRecord  ) ; 

NumberjofJTasks  ;=  Number_ofJTasks  +  1? 
end  if; 

end  ReleaseJTask; 
end  select; 
end  loop; 

end  Counting  jSemaphoreJTaskJType ; 


end  GenericjCcunt  ingJ5emaphoreJManager_Package ; 

2  -  9.12  Exanple  of  Tasking 

Example:  This  example  illustrates  misted  generalized  mechanisms  to 

control  and  regulate  intertask  communications  with  mailboxes. 

with  Mandatory_Access_Control_Types_Package ;  —  see  3  -  3.1.3 

generic 

4 Wnecarto  fpimo  ie  nri  x • 

Max_Number_ofJtessages  :  in  NATURAL  :=  24; 
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package  Generic_Mailbox_Manager_Package  is 

procedure  Send  (  Message  :  in  Message_Type; 

Local_MAC_Hecord  :  in 
Maindatory_Acoess_Control_TVpes_Package . 

MAC_Record_Type  ) ;  —  see  3  -  3.1.3 

prooeduro  Receive  (  Message  :  out  Message Jtype ; 

LocalJ^ACJtecord  :  in 
Mandatory_Aocess_Ooritrol JTypes_Package . 
MAC_RecordJfype  ) ;  —  see  3  -  3.1.3 


end  Generic_Mailbox_Manager_Package? 


with  Mandatory_Aocess_Control_Manager_Pac3cage;  —  see  3  -  3.1.3 
with  Aix3itJPrail_Managex-_Package ;  —  see  3  -  3.2.3 
package  body  Generic_Mailbox_Manager_Package  is 


task  ManagerJTask  is 

entry  Deposit  (  Message  :  in  Message  JType; 

Other _lxisk_MAC_Record  :  in 

Mar>datory_Acoess_Control__Types_Package . 

MAC_Record_Type  ) ;  —  see  3  -  3.1.3 


entry  Remove  ( 


end  ManagerJTask; 


Message  :  cut  Message_Type? 

Other_Task_MAC_Record  :  in 

Mardatory_Access_Control_Types__Package . 

MAC_Record_Type  ) ?  —  see  3  -  3.1.3 


procedure  Send  (  Message  :  in  MessageJType; 

Local_MAC_Fecord  :  in 
Manda  tory^Access^GmtrolJTypesJPackage . 

MACmRecord_Type  )  is  —  see  3  -  3.1.3 

begin 

ManagerJTask.  Deposit  (  Message,  Local_MAC_Record  ) ; 
end  Send? 


procedure  Receive  (  Message  :  oat  MessageJType; 

Incal_MAC_Record  :  ir.i 
Mandatc^_Access_Ctntrol JTypesJPackage . 
MAC_Recortl_Type  }  is  —  see  3  -  3.1.3 
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begin 

Manager_Task.  Remove  (  Message,  Local_MAC_Record  ) ; 
end  Receive; 


task  body  ManagerJTask  is 

subtype  Mailbox_Slot_IndexJiype  is  INTEGER  range 
0  . .  (  Max_Number_of_Messages  -  1  ) ; 

Head_Slot  :  Mailbox_S lot_Index_Type  :=  0; 

Tail_Slot  ;  Mailbox_SlotJtndexJiype  :=  0; 

Message_Nurtiber  ;  INTEGER  range  0  ..  Max_Number_of_Messages ; 


Mailbox  :  array  (  Mailbox_Slot_Index_Type  )  of  Message_Type; 
Iocal_MAC_Record  : 

Mandatory_AcoessjOontrol_iypes__Backage .  —  see  3  -  3.1.3 

MAC_Record_Type ; 

Other_Task_MAC_Record  : 

Mandatory_Access_ControlJTypes_Package .  —  see  3  -  3.1.3 

MAC_Record_Type ; 


begin 

loop 

select 

when  Kessage_Number  <  Max_Nuiriber_of_Messages  => 

accept  Deposit  (  Message  ;  in  Message_Type; 

Other_Task_MAC_Record  :  in 
Mandatory__Access_Control_Types_Package . 
MAC_Record_Type  )  do 

—  see  3  -  3.1.3 

if  Mardatory_Access_Control_Manager_Package. 

Sens  it  ivity_Iabe1  s_Match  —  see  3  -  3.1.3 

(  Iocal_MAC_Record.  Sensitivity_Label, 
OtherJEask_MACJEtecord . 

Sens it ivity_Iaoel  )  then 

Audit_Trail  _Manager_Package .  —  see  3  -  3.2.3 

Log_Sub j  ects_Access_to_Ob j  ect_in_Audit_Trail  ( 
Local_MAC_Ra^ord,  Other_Task_MAC_Record  ) ; 
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Mailbox  (  Head_Slot  )  :=  Message; 

Headjslot  :=  (  Headjslot  +  1  )  mod 
Max_Number_of_Messages ; 

Message_Number  :=  Message_Number  +  1; 
end  if? 
end  Deposit; 


or 

when  Message J^umfcar  >  0  => 

accept  Remove  (  Message  :  out  Message_  Type; 

Other__Task_MAC_Record  :  in 
MandatorY_Access_Contrcl_Types_Package . 
MAC_Record_Type  )  do 

—  see  3  -  3.1.3 

if  Mandatory_Access_Control_Manager_Package . 

Sens  it  ivity_Labels_Matdi  —  see  3  -  3.1.3 

(  I^cal^^CJRecxjrd.  Sensitivity_Label , 

Other _Task_MAC_Reoord. 

Sensitivity_Label  )  then 


Audit  jTrail_Manager_Package.  —  see  3  -  3.2.3 

Log_Sub j  ec£s_Acx^ss_to_Ob j  ect_in_Audit_Trail  ( 
local JMAC_Record,  Other_Task_MAC_Record  ) ; 

Message  ;=  Mailbox  (  Head_Slot  ) ; 

Tail_Slot  ;=  (  Tail_Slot  +  1  )  mod 
Max_Number_of_Messages ; 


Message_Number  ;=  Message_Number  -  1; 
end  if; 
end  Remove; 
end  select? 
end  loop; 
end  Manager_Task; 

end  Ger.?ric_Mailbox_Manager  _Package; 
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11.  Exceptions 

Example:  This  example  illustrates  trusted  exception  handling  that  allows 
program  execution  to  continue  in  a  trusted  manner. 

generic 

***“  •  «  « 

type  Namejiype  is  private; 
type  ACL_Record_Type  is  private; 


package  Generic_Access_Control_List_Manager_Package  is 


procedure  Get_ACL_Record 

(  Name  :  In  Namejiype; 

ACLJRecord  :  cut  ACL_RecordJiype  ) ; 

procedure  Insert_AQi_Record 

(  ACL_Record  :  in  ACL_RecordJType  ) ; 

procedure  Delete_ACL_Record 
(  Name  :  in  Namejiype  ) ; 


Cwerflow_Access_Control_List  :  exception; 
Access_Control_List_i s_Nul  1  :  exception; 

private 


end  Generic_Access_Control_List_Manager_Package; 


with  Access_Control_ListJiypes  Package; 

with.  rlandatoiyjAcx^^_controljrypes_Fackage;  —  see  3 
with  Mandatory_Access_Control_Manager__Package ;  —  see  3 
with  AuditJTrail_Manager_Pac)3ge ;  —  see  3 
package  body  Generic_Access_Control_List_Manager_Package  is 
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—  Hie  user  can  gain  only  indirect  access  to  instantiated 

—  access  control  list  through  the  subprograms  declared  in  the 

—  package  specification.  Thus  the  access  control  list  data 

—  structure  is  hidden  fran  the  user  of  this  package.  Hie 

—  typical  list  manipulation  operations  (  e.g. ,  as  illustrated 

—  by  Booch  1987A  and  Feldman  1985  )  are  only  provided  in  the 

—  package  body. 


ExceptionJRaiser JRecord : 

Mandatory_Acoess_Oontrol Jiypes_Package .  —  see  3  -  3.1.3 

MAC_Record_Type ;  ~  —  Initialize  Exception_Raiser_Record . 


Exception JlandlerJRecord  : 

Mardatory_Access_Control_'iypes_Package.  —  see  3  -  3.1.3 

MAC_Record_Type ;  —  Initialize  Except ion_Handler_Record . 


—  Typical  list  manipulation  operations 


procedure  Get_ACL_Record 

(  Name  :  in  Name_Type; 

ACL_Record  :  out  ACL_Pecord_Type  )  is 


Exception_Name  : 

Mandatory_Access_Control_riypes_Package .  —  see  3  -  3.1.3 

Exception_Naroe_Type  := 

Mandatory_Access_Control_Types_Package . 

Others_String ; 


begin  —  Get_ACL_Record 


—  Sequence  through  the  access  control  list  data  structure 

—  using  the  typical  list  manipulation  operations  to  locate 

—  and  get  the  indicated  access  control  list  record. 
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exception 


when  others  => 

Audit_Trail_Manager_Package .  —  see  3  -  3.2.3 

Iog_Exception_in_Aiid  i  t_Trail  ( 

Exception_Name , 

Excej±ionJteiserJRec»rd^ 

EXception_Handler_Record  ) ? 

end  Get_ACL_Record ; 


procedure  Insert_ACL_Record 

(  ACL_Record  :  in  ACL_Record__Type  )  is 


•  •  • 

ExceptionJName  : 

Mardatory_Access  J3ontrol_Types_Package .  —  see  3  -  3.1.3 

Exception_Name_Type  := 
Mandatory_Access_ControlJiypes_Package . 

Others jstring; 


begin  —  Insert_ACL_Record 


—  Sequence  through  the  access  control  list  data  structure 

—  using  the  typical  list  manipulation  operations  to  locate 

—  the  appropriate  place  to  insert  the  indicated 

—  access  control  list  record.  This  location  is 

—  determined  by  a  predefined  mechanism,  e.g.,  alphabetizing  by 

—  the  "name"  of  the  access  control  list  record,  or  more 

—  crudely  by  a  simple  (FIFO)  stack  or  (FIIO)  queue. 


—  Check  for  the  exception  Overflcw_Access_Control_List. 

—  If  the  exception  is  to  be  raised,  then  set  the 
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—  Exception_Na.i.e  and  Except  ion_Raiser_Record. 


exception 


when  C>/erflcw_Access_Control_List  => 

Audit_Trail_Manager_Package .  —  see  3  -  3.2.3 

Log_Exception_in_AuiitJItail  ( 

Exception_Name , 

Except  ionJRaiser_Record , 

Exception JiarrilerJRecord  )  ; 


when  others  => 

AuditJItail__Manager_Package .  —  see  3  -  3.2.3 

Log_Exception_:mJ^  ( 

Except ion_Name , 

Exception_Raiser_Record , 

Exception JrIandler_Record  ) ; 

end  Insert  ACL  Record; 


procedure  Delete_ACL_Record  (  Name  ;  in  Name_Type  )  is 


Exception_Name  ; 

Mandatory_Access_Control_Types_Package.  —  see  3  -  3.1.3 
Exception_Name_TVpe  ;= 
Handatory_Access_Control_Types_Package . 

Others_String; 


begin  —  Delete_ACL_Record 


—  Sequence  through  the  access  control  list  data  structure 

—  using  the  typical  list  manipulation  operations  to 

—  locate,  scrub,  and  delete  the  indicated 
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—  access  control  list  record. 


—  Check  for  the  exception  Access_CcxTtrol_Iisrt_is_i4ill . 

—  If  the  exception  is  to  be  raised,  then  set  the 

—  Exception_Name  and  Except ion_Ra  iser_Record . 


exception 


when  Acxess_Control_List_is_Null  => 

Audit_Trail_Manager_Package .  —  see  3  -  3.2.3 

Lcg_Exception_in_Aixiit_Trail  ( 

Except ion_Name , 

Except  ion_Raiser_Record , 

EXception_HandlerJRecord  ) ; 


when  others  => 

Audi  t_Tra i  l_Manager_Package .  —  see  3  -  3.2.3 

Iog_Exception_in_Audit_Trail  ( 

ExceptionJName , 

Exception_Raiser_Record, 

Exception Jlandler_Record  ) ; 

end  Delete_ACL_Record; 


end  Gener ic_Access_Control_List_Manager_Package ; 

2  -  12.4  Example  of  a  Generic  Package 

Example:  Ihis  example  illustrates  a  generic  package  for  multiple  instances 
of  an  access  control  list,  with  instantiations  of  the  package. 

generic 
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type  Name_Type  is  private? 
type  ACL_Record_Type  is  private; 


package  Generic_Access_Control_Ldst_Manager_Package  is 


procedure  Get_ACL_Reoord 

(  Name  :  in  Name_Type; 

ACL_Record  :  out  ACL_Record_Type  ) ; 

procedure  Insert_ACLJRecord 

(  ACLJRecord  :  in  ACLjRecordJType  ) ; 

procedure  Delete_ACL_Reoord 
(  Name  :  in  Name_Type  ) ; 


Overflcw_Access_Control_List  :  exception; 
Access_Control_List_is_Null  :  exception; 

private 


end  Generic_Access_Control_List_Manager_Package ; 


with  Acx^ss_Control_Listjrypes_Fackage? 

with  Mandatcry_Access_Control_Types_Package ;  —  see  3  -  3.1.3 

with  Mandatory_Access_Control_Manager_Package;  —  see  3  -  3.1.3 

with  AuditJTrail_Manager_Package ;  —  see  3  -  3.2.3 

package  body  Generic_Access_Control_List_Manager_Package  is 

—  Ihe  user  can  gain  only  indirect  access  to  instantiated 

—  access  control  list  through  the  subprograms  declared  in  the 

—  package  specification.  Ihus  the  access  control  3.1st  data 

—  structure  is  hidden  from  the  user  of  this  package.  The 

—  typical  list  manipulation  operations  (  e.g. ,  as  illustrated 

—  by  Booch  1987A  and  Feldman  1985  )  are  only  provided  in  the 

—  package  body. 
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—  Typical  list  manipulation  operations 


procedure  Get_ACL_Record 

(  Name  :  in  Name_Type; 

ACL_Record  :  out  ACLJRacord_Type  )  is 


begin  —  Get_ACL_Record 


—  Sequence  through  the  access  control  list  data  structure 

—  using  the  typical  list  manipulation  operations  to  locate 

—  and  get  the  indicated  access  control  list  record. 


end  Get_ACL_Recortf ; 

procedure  Insert_ACL_Record 

(  ACL_Record  :  in  ACL_Record_Type  )  is 


begin  —  Insert_ACLJRecord 


—  Sequence  through  the  access  control  list  data  structure 

—  using  the  typical  list  manipulation  operations  to  locate 

—  the  appropriate  place  to  insert  the  indicated 

—  access  control  list  record.  Ibis  location  is 

—  determined  by  a  predefined  mechanism,  e.g. ,  alphabitizing  by 

—  the  "name"  of  the  access  control  list  record,  or  more 

—  crudely  by  a  simple  (FIFO)  stack  or  (FIIO)  queue. 


end  Insert_ACL_Record; 
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procedure  Delete_ACL_Record  (  Name  :  in  Namejiype  )  is 


begin  —  Delete_ACLJReoord 


—  Sequence  through  the  access  control  list  data  structure 

—  using  the  typical  list  manipulation  operations  to 

—  locate,  scrub,  and  delete  the  indicated 

—  access  control  list  record. 


end  Delete  ACL  Record; 


end  Generic_Access_Control_List_Manager_Package ; 


—  Instantiations  of  Generic_Access_Contrcl_List_Manager_Package 
package  NairedJDbjects_Access_Control_List_Manager_Package  is  new 
Generic_Access_Control_List_Manager_Package 
(  Namejiype  =>  Bas  ic_TCB_Types_Package . 

Name_ofj3bj  ect_Type , 

ACL_RecordJiype  =>  Access_Control_List_Types_Package . 

NamedjDb j  ect_Record_Type  ) ; 


package  N'amed_Individuals_Access_Control_List_Manager_Package  is  new 
Generic_Access_Control_List_Manager_Package 
(  Namejiype  =>  Bas  ic JICBJTypes JPackage . 

NaroejofjObj  ectJType , 

ACL_Record_Type  =>  Access j^ntrol_Listjrypes_Package. 

Named_Individual_RecordJiype  ) ; 
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package  Groups_of_Named_Individuals_ACL_Manager_Package  is  new 
Generic _Access_Control_List_Manager_Package 
(  Name_Type  =>  Basic_TCBJiypes_Package . 

Neunejof _Obj  ectjiype, 

ACL_Record_Type  =>  Access_Control_List_Types_Package . 

Grtx^_of_Naii^_Individuals_Recordjrype  ) ; 


2  -  13.5.1  Internets 


Example:  This  example  illustrates  trusted  interrupt  handling. 

Note  that  address  clauses  are  not  currently  supported  in  VAX  Ada. 

with  Mandatory_Acxxss_Control_Types_Package ;  —  see  3  ~  3.1.3 

package  !InterruptJHandler_Package  is 


procedure  GetjCharacter  (  Char  :  out  CHARACTER; 

Local_NAC_Record  :  in 
Mandatory_Acx3ess jControl jTypes_Package . 
MAC_Record_Type  )  ?  —  see  3  -  3.1.3 


procedure  PutjCharacter  (  Char  :  in  CHARACTER; 

Iocal_hAC_Record  :  in 
Mandatory_Access_CPntrolJPypes_Package . 
MAC_Record_Type  );  —  see  3  -  3.1.3 


end  Interrupt_Handler_Package; 


with  Mandatory_Accessj3ontrolJMaragerJRackage ; 
with  Audit_Trail_Manager_Package ; 
package  body  lnterrupt_Handler_Package  is 


—  see  3  -  3.1.3 

—  see  3  -  3.2.3 


task  Interrupt_InputJiardlerJTask  is 
pragma  PRIORITY  (  4  )  ? 

—  must  have  at  least  the  priority  of  idle  interrupt 

entry  Get_Character_fran  Interrupt  JLnput  Address 
(  Char  ~  ;  out  CHARACTER; 

OtherJTask_MACJRecord  :  in 
Mandatory_Access_Control_T\7pes_Package . 

MACJRecord_Type  )?  ~  —  see  3  -  3.1,3 
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entry  Save_Hardware_Buf  f  er_Character  ( 

Other_Task_MAC_Record  :  in 
Mandatory_Acxess Jhntrol Jiypes_Package . 

MAC_Record_Type  ) ?  —  see  3  -  3.1.3 

—  assuming  that  SYSTEM.  ADCRESS  is  an  INTEGER  type 
far  Save_Harr3ware_Buffer_Character  use  at  16#0020#; 

end  Intempt_Irput_HandlerJTask; 


task  InterrvptjCutputJiandlerJTask  is 
pragma  PRIORITY  (  4  )  ? 

—  must  have  at  least  the  priority  of  the  interrupt 

entry  Depos  it_Charac±er_into_Hardware_Buf  f er  ( 
Other_Task_MAC_Record  :  in 

Mandatory_Acoess_Control_Types_Package . 

MACJRecord_Type  ) ;  —  see  3  -  3.1.3 

entry  Put_Character_into_Interript_Output_Address  ( 

Char  :  in  CHARACTER; 

Other_TaskJMAC_Record  :  in 

Mandatory_Access_Control_Types_Package . 

MAC_Record_Type  );  —  see  3  -  3.1.3 

—  assuming  that  SYSTEM.  ADDRESS  is  an  INTEGER  type 

for  Depos it_Character_into_Hardware_Buf f er  use  at  16^0024^; 

end  Interrupt_Output_Handler_Task ; 


prooedure  Get_Character  {  Char  :  out  CHARACTER? 

Local_MAC_Record  ;  in 
Mandatory'_Acc^ss_Control _iypes_Package . 
MAC_RecordJType  )  is 

—  see  3  -  3.1.3 

begin  —  GetjCharacter 

]hterrupt_Ihput_Harmer_Task . 
GetjCharac±er3from_Ihterrupt„Inpjt_Address 
(  Char,  Local JMAC_Reeord  )  ? 

end  Get  Character; 
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procedure  Put_Character  (  Char  :  in  CHARACTER; 

Local_MAC_Record  :  in 
Mar*3atori'_Access_Control Jfypes JPackage . 
MACJteoozdJType  )  is 

— ■  see  3  ~  3.1.3 


begin  —  Put_Character 


]nterr^^_(>n5)ut_Haridler_Task . 

Put  _Character_intc_Interri^_CWt^xit_Ad^ 
(  Char,  Local_MAC_Record  ) ; 

end  Put  Character; 


task  body  Interri^_IrputJiandler_Task  is 

Max_Size_cf_Internal_Input_Buffer  :  constant  POSITIVE 
:=  64; 

Interral_Irput_Buffer  ; 

array  (  1  ..  Max_Size  of_Internal  Ihput  Buffer  ) 

Of  CHARACTER; 

Input_Buffer_Po inter  ;  POSITIVE  :=  1; 

Output_Buffer_Po inter  :  POSITIVE  ;=  1; 

Buffer_Count  ;  INTEGER  :=  1; 

Hardware_Character_Buffer  ;  CHARACTER; 

for  Hardware_Character_Buffer  use  at  16#0100#; 

Iocal_InputJTask_MAC_Record  : 

Mandatory_AccessjControl JTypes_Package .  —  see  3  -  3.1.3 

MAC_Record_Type ; 

Other_Task_MAC_Record  ; 

Mania tory_Access_Control_Types_Package .  —  see  3  -  3.1.3 

MAC_Record_Type ; 

begin  —  Interrupt_Iiput_Handler_Task 
loop 
select 

\*en  BufferjCount  >  0  => 
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accept  Get_Character_frori_Internpt_Irput_Mdreas 

(  Char  :  cut  CHARACTER; 

Other_Task_MAC_Record  :  in 
Mandatory_A£^ess_ControlJTypes_Fackage . 
MAC_Record_iype  )  do 

—  see  3  -  3,1.3 


if  Mardatory_Access_tontrol_Manager_Package. 

Sensitivity_Labels _Match  —  see  3  -  3.1.3 

(  Jlnput JEa^  . 

Sensitivity_Label ; 

Other JTaskJ^_Fecx>rd. 

Sensitivity_Label  )  then 

Aj^tJTtail_Marager_Pac*age.  —  see  3  -  3.2.3 
Lcg_Sub  j ecte__Access_to_Cto j ect_in_Audit_Trail  ( 
Docal_Irput_TaskJ^C_Record , 

Other JTasJcJHAC_Recorti  ) ; 

Char  :=  Internal_Irput_Buf f  er  ( 

Output_Buf f er JPointer  ) ; 

cutputJBuffer_Pointer  := 

Output_Buf  f  er_Pointer  mod 
Max_Sizej3f_Internal_IxputJBuffer  +  1? 

Boffer_Count  :=  Buffer_Count  -  1; 
end  if; 

end  Get_C3iarac±er_fram_Interrupt_Iiput_Address; 


or 

*>foen  Baffer_Count  < 

Max_Size_of_Internal_]jput_Baffer  => 


accept  Save_Hardware_Buf  f erjCharacter  ( 
Other_Task_MAC_Record  :  in 

Mandatory_Access J3ontrol JTypesJPackage . 
MAC_Record_Type  )  do  —  see  3  -  3.1.3 


if  Mandatory_Access_Control_Manager_Package . 

Sens  it  ivityJLabel  s_Match  —  see  3  -  3.1.3 

(  l JjCclL'—XI ipu oSr^i,Jrt'w^rv»^ j. <u . 

Sensitivity_Label , 

Other_Task_MAC_Ftecord . 

Sensitivity_Label  )  then 
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Audit_Trail_Mana>-jer__Package .  —  see  3  -  3.2.3 

Iog_Sub j  ects_Access_to_Ob j  ect_in_Audit_  Trail  ( 
local  .Input JTaskJ4ACJtecord , 
Otlxir~Task_MAC_Record  )  ; 

Internal_lrpat_Buf  f er  ( 

Iipao_  _Baf f er~Fointer  } 

Haxrt^are_Cliaracter_Euffer ; 

Inp^JBufferjPointer 

Itput_BofferJPoinber  nod 
Kax_Sise_of_Irternad_Input_Bofffer  +  1; 

Buf£er_Count  Buffer_Count  +  1; 
erd  if; 

end  SavoJiardvareJBuf  f  er_Character  ; 
end  select; 
end  loop; 

end  totsrrupt_In^t_Hardler_Task  ; 


task  body  Interrupt_OutputJiard^  is 

Max_Sizejof_Internalj3utput_Boffer  :  constant  POSITIVE 
:=  64; 

Intemal__Output_Buffer  : 

array  (  1  . .  Max_S  i  ze_of _Intemal_Datput_Bnf  f er  ) 

Of  CHARACTER; 

Input_Buf  fer_Po inter  :  POSITIVE  :=  1; 
Output_Buffer_Pointer  :  POSITIVE  :=  1; 

Buffer_Count  ;  INTEGER  :=  1; 

Hardware_Cha.racter_Baf f er  :  CHARACTER; 

for  Hardv^are__Cliaracter_Baffer  use  at  16#0200#; 

Hardware_Character_Buffer_is_>Eipty  :  BOOLEAN  ;=  TRUE; 

LDcaI_OutputJTasl^_MAC_Record  : 
Mandator^’_A,ccess_CcntrolJl^pes_Pac>sge.  —  see  : 
MAC_Record_iype ; 
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Other_Task_MAC_Record  : 

Mardatory_Access_Control_TVpes_Package.  —  see  3  -  3.1.3 
MAC__Record_Type ; 

begin  —  Intern^_CXitpat_HandlerJI^^ 
loop 
select 

accept  Deposit_Charac±er_into_Harc3wa>:e_Baffer  ( 

Other JIask_MAC_Record  :  in 
Mardatory_Aooess_Control_Types_Package . 

MACJRecordJiype  )  do  —  see  3  -  3.1.3 


if  Mandatory_Aa3ess  Q>ntrolJ4amger_Pacdcage. 

Sensitivity_Labels_Match  —  see  3  -  3.1.3 

(  Lacal  jCutput_Tas^  . 

Sensitivity_Label , 

Other JTask_MAC_Record . 

Sensitivity_Label  )  then 

Ai^t_Trail_Manager_Package .  —  see  3  -  3.2.3 

IogjSubjec*s_Access_toj3bject_in_Auditjrrail  ( 
Ioc^jDutput_Task_MAC_Record , 
Other_Task_MAC_Record  ) ; 

if  BufferjCount  >  0  then 

Hardware_Character_Buffer  := 

Intemal_Oatput_Baf  f er  ( 

Oatput_Baffer_Pointer  ) ; 

Outpu  t_Buf  f er_Po inter  := 

Output  J3uffer_Pointer  mod 
Max_SiEe_of_Intemal_Output_Buffer  +  1; 

Buffer_Count  :=  Buffer_Count  -  1; 

else 

Hardware_Character_Baf f er_is_Empty  :=  TRUE; 
end  if; 
end  if; 

end  Depos  it_Character_into_Hardware_Buf  f  er ; 
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when  Buffer_Count  < 

Max_Size_of_Interr^jDutput_Boffer  => 

accept  Putj3iaracter_intoJhterruptjDutputJddress 
(  Char  :  in  CHARACTER? 

Other  JTask_MAC_Reoord  :  in 

Mandatory_Aoaess_Control_Types_Package . 
MAC_Record_Type  )  do  —  see  3  -  3.1.3 

if  Mardatory J^ocess_Cantrol_Manager_Package . 

Sensitivity_Labels_Match  —  see  3  -  3.1.3 

(  Loc^_Output_TaskJ^JRecord . 
SensitivityJLabel , 

Other JTask_MAC_Record . 

SensitivityJLabel  )  then 

Audit_Trail_Manager_Package.  —  see  3  -  3.2.3 

LogjSub j  ects Juscess Jx>_Ob j  ect_in_Audit_Trail  ( 
Local_Output_TaskJ^C J^ecord , 

Other _Task_MAC_Record  ) ? 

InterraljOutputJBuffer ( 

Input_Buf f  er_Pointer  )  :=  Char; 

Input_Buffer_Pointer  := 

Input_Buf  f er  JPointer  mod 
Max_S  i  z  e_of_Intemal j3utput_Buf  f er  +  1? 

Buffer_Count  :=  Boffer_Count  +  1; 

if  Harch-rare_Character_Buffer_is_Enjpty  then 

HardwarejCharacter_Buffer  := 
Intemal_Output_Buffer  ( 

0,atput_Buffer_Po  inter  ) ; 

CXitput_Buffer_Bointer  := 

Output JBufferJftxinter  mod 
Max_Size_of_InternaljOutput_Buffer  +  1; 

Baffer_Count  :=Buffer_Count  -  1; 

Hardware j3iaracter_Buffer_is_Enpty  TRUE? 

end  if; 
end  if; 

end  Put_Character_into_Interrupt_cnatput_Address  ; 
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end  select; 
end  loop; 

end  Intern^_OiQx±_Handler_Task  ? 
end  Iriterrupt_Handler_Package? 


2  -  13.9  Irrterfaoe  to  Other  Languages 

Example:  This  example  illustrates  the  interface  of  Ada  with  Pascal. 

package  Graphics_Library_Package  is 
procedure  Draw_Circle 

(  Center  :  in  Coordinates_Type; 

Radius  :  in  DistanceJType  ) ; 


private 

pragma  INTERFACE  (  PASCAL,  DrawjCircle  ) ; 


•  •  • 

end  Graphics_Library_Package; 


2  -  14.7  Example  of  Input-Output 

Example:  This  example  illustrates  trusted  input  and  output, 
with  TEXT_IO; 

with  Mandatory_Access_Control_TVpes_Pac}cage;  —  see  3  -  3.1.3 

with  Access_Control_List_TVpes_Package; 

generic 

Max_Characters_in_Message  :  POSITIVE  :=  80; 
package  Generic_Sensitive_Text_File_Manager_Package  is 
Sensitive_Text_File  :  TEXTJEO.  FUEJIYPE; 

subtype  Message_Type  is  STRING  (  1  ..  Max_Qiaracters_in_Message  )  ; 
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procedure  PutJLine  ( 

Subject_MAC_Record  :  in 

Mandatory Jux>sssJ»ntrolJ?ypesJ3ackage . 
MAC JtecordJiype  ? 

Named jDbjert_MACJRecord  :  in 

Mandatory JtooessJ2ontro.l_  Types J>ackage . 
MAC_Record_Type ; 

...  Message  -  ■  :  in  Messagejtype  ); 


end  Gener ic_Sensitive_Text_File_Manager_Package  ; 


with  Mardatory_Access_Control_Manager_Package ?  —  see  3  -  3.1.3 
with  Audit JLrailJtonagerJPackage ;  —  see  3  -  3.2.3 
package  Generic_Sensitive_Text_File_Manager_Package  is 


procedure  PutJLine  ( 

Sub j  ec± J4AC Jtecord  :  in 

Mandatory_Aocess _Control _Types_Pac)cage . 

MAC Jtecord_Type ; 

Named J)b j  ect_MACJtecord  :  in 

Mandatory JvccessjLontroljypesJ’ackage . 
MAC_Record_Type ; 

Message  :  in  Message_Type  )  is 


begin  —  PutJLine 

if  Mandatory_Access_ControlJfanager_Package. 

Sensitivity JabelsJfctch  —  see  3  -  3.1.3 

(  Subject_MAC_Record.  Sensitivity JLabel , 
NamedjDbjectJIACJlecord.  Sensitivity_Iabel  )  then 

Auait_Trail_Manager_Package .  —  see  3  -  3.2.3 

Log_Subj  ects_Access JxjObj  ect_in J^.udi t_Tra  il  ( 
Subject_MAC_Racord,  Named_Ob j  ect  JIAC_Record  ) ; 
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TEXT_IO.  KJT_LINE  (  Sensitive_Text_File,  Message  ) ; 

end  if? 
end  Put_Line? 

**“  •  •  • 

end  Generic_Sensitive_Text_File_Manager_Package ; 
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3.1.1  Discretionary  Access  Control 

Example:  This  example  illustrates  a  generic  package  specification  for 
multiple  instances  of  user  identification  and  authentication 
(The  package  body  is  in  Section  3  -  3.2.1.) 

with  Mandatory  JAcoess_Controljrypes_Package ;  —  see  3  -  3.1.3 

with  Generic_Access_Control_T  .i  st_Mar*ager_Package ; 

generic 


type  Passwordjiype  is  private; 


package  Generic_User_Identification_and_Authentication_Package  is 


procedure  Check_Password 

(  Password  ;  in  Passwordjiype; 

Local_MAC_Record  ;  in 

Mandatory_Access_Control_Types_Package.  —  see  3  -  3.1.3 
MAC_Record_Type ; 

Password_is_Valid  :  out  BOOLEAN  ) ; 


end  Generic_User_Identification_and_Authentication_Package ; 
3.1.3  labels 

Example:  Sensitivity  label  type  declaration 
with  Basic_TCS_Types_Package ; 

package  Mandatory_Access_Controljrypes_Package  is 


subtype  Name_of_Resouroe_iype  is  s 

Bas  ic_TCB Jiypes_Package .  NaireJStringJType  ; 
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subtype  Sensitivity_Iabel_Type  is 

Bas ic_TCB_Types_Package .  Name_String_Type ; 

Scrubbed_Sensitivity_Label  :  Sensitivity_Label_Type 
:=  Basic_TCB_Types_Package .  BlarikJteite_String; 

subtype  Exception_Name_Type  is 

Basic_TCB_Types_Package .  Nane_Stxing_iype ; 

Scrubbed_Exception_Name  :  Exception_Na]me_Type 
:=  Bas icJK3_Types_Package .  Blank_Name_String; 

Others_String  :  Bas  ic_TCB_'iypes_Package .  NeareJString_Type 
:=  Basic_TCB_Types_Package .  Blank_Name_String? 

type  MAC_RecordJiype  is 
record 

Name  :  Namejof  JResourceJiype 

:=  Basic_TCB_Types_Package .  Blank_Name_String ;  —  see  2  -  3.2.1 

Sensitivity_Label  :  Sensitivity_Label_Type 
:=  Scrubbed_Sensitivity_IabelT 


end  record; 


end  Mandatory_Acx^ss_Control_Types_Package; 


with  Basic_TCB_‘iypes_Package; 

with  Mandatory_Access_Control_'iypes_Package ; 

package  Mardatory_Access_Control_Mariager_Package  is 


function  Sensitivity_Labels_Match 
(  Sensitivity_Label_A  :  in 

Mardatory_Access_Control_Types_Package . 

4>4«r44^r  T  fTVi  tv-w->  • 

iox  ux  v  j.  i/y  AjniJcx  j.y  / 

Sensitivity_Iabel_B  :  in 
Mardatory_Access_Control_Types_Package . 
Sensitivity_Iabel_Type  ) 
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return  BOOLEAN; 


end  Mandatory_Access_Control_Manager_Pack2»ge ; 


3.2.1  Identification  and  Authentication 

Example:  This  example  illustrates  a  generic  package  body  for  multiple 
instances  of  user  identification  and  authentication .  (The 
package  specification  is  in  Section  3  -  3.1.1.) 

with  Acoess_Oontrol_List_Types_Package; 

with  Audit_Trail_Manager_Package;  —  see  3  -  3.2.3 

package  body  Generic_User_Identification_and_AuthenticationJPackage  is 


procedure  Check_Password 

(  Password  :  in  Password_Type; 

Iocal_MAC_Record  :  in 

Mardatory_Access_Control_Types_Package.  —  see  3  -  3.1.3 
MAC_Record_Type ; 

Password_is_Val id  :  out  BOOLEAN  )  is 


begin  —  Check_Password 


end  Check  Password; 


end  Generic_User_Ident.ification_and_Authentication_Package; 


C-157 


appends:  c 

Collection  of  E>ainples 


3-2.3  Audit 

Example:  Audit  trail  manager  package 
with  TEXTIO; 

with  Mandatory_Acc»ss_Control JTypes_Facklage ;  —  see  3  -  3.1.3 

package  Audit  JTrail_Marager_iackage~* is 


AuditJTrail_Text_File  :  TEXTJEO.  FILEJIYEE; 


•  •  • 

procedure  Iog_Sub j  ects_Access_to_Ob j  ect_in_Audit_Trail  ( 

Sub j  ect_MAC_Record  :  in 

Mardatory_Access_Control _Types_Package .  —  see  3  -  3.1.3 

MACJRecord_Type ; 

Named_Qb  j  ect_MAC_Record  :  in 

Marriatory_Acr«ss_Control Jiypes_Package .  —  see  3  -  3.1.3 

MACJRecordJType  ) ; 


procedure  Iog_Exception_in_Audit_Trail  ( 
Exception_Name  :  in 

Mandatory_Access_Control_Types_Package . 
Exception_Name_'iype  ; 

Exception_Raiser_Record  :  in 
Mandatory_Access_Control_Types_Package . 
MAC_Rec»rd_Type ; 

Exception_Handler_Record  :  in 
Mandatory_Access_Control_Types_Package . 
MACJRecordJType  ) ; 


—  see  3  -  3.1.3 


—  see  3  -  3.i:3 


—  see  3  -  3.1.3 


end  Audit_Trail_Manager_Package; 
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with  Mandatory_Access_Control_Manager_Package  ; 
package  body  Audit_Trail_Manager_Package  is 


prooedure  Iog_Sub j  ects_Aocess_to_Ob j  ec±_in_Audit jrrail  ( 
Subject_MACJSecon3  :  in 

Mandatory_Access_Control_Types_Package .  —  see  2  -  3.1.3 

MAC_Recx>rd_Type ; 

Named_Ob j  ect_MAC_Recood  :  in 

MarKiatory_Acc«sE_Control_Types_Package .  —  see  3  -  3.1.3 

MAC_Record_Type  )  is 


begin  —  Iog_Sub j  ects_Access_to_Ob j  ect_in_Audit_Trail 


TE3CT_I0.  HJTLINE  (  Alldit_Trail_Text_File , 

"Subject  "  &  Sub  j  ect_MAC_Record .  Name  )  ? 

TEXTJEO.  Krr_UNE  (  Audit_Trail_Text_File , 

"  is  not  authorized  to  access  "  & 
NamedjObject_MAC_Record.  Name  ) ; 


end  Icg_Sub j  ects_Access_to_Ob j  ect_in_Audit_Trail ; 


prooedure  Log_Except ion_in_Audi t_Tra i 1  ( 

Exception_Name  :  in 

Mardatory_Access_Ct)ntrol_Types_Package .  —  see  3  -  3.1.3 

Exception_Name_Type ; 

Exception_Raiser_Record  :  in 

Mandatory_Access_Control_lVpes_Package.  —  see  3  -  3.1.3 
MAC_Record_'iype ; 

Exception_Handler_Record  :  in 

Mandatory_Access_Control_,IVpes_Package.  —  see  3  -  3.1.3 
MAC_Record_Type  )  is 
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begin  —  LDg_Exc^ption_in_AL^tJTredl 


if  Mandatory_Accessj3ontrolJManagerJPackage. 

Sensitivity_Labels_Match  —  see  3  -  3.1.3 

(  Exc«ption_Har>dler_Record. 

Sensitivity_Iabel , 

Exception_Raiser JRecord . 

Sens  itivity_Label  )  then 

TEXTIO.  FUTJLINE  (  Aiidit JIiailjrext_File , 

"Subprogram  "  & 

Exception_Handler_Record .  Name  & 

"  handled  the  exception,  "  ) ; 

TEXTJCO.  PUTJLINE  (  Audit_Trail_Text_File ,  »  ",  & 

Exoeption_Name  &  "  raised  by  "  & 
Exoeption_Raiser JRecord.  Name  )  ; 

else 

TEXT_IO.  RJTJZNE  (  AuiitJIlrail_Text_File , 

"Subprogram  "  & 

Exc^tionJHardler_Record.  Name  & 

"  is  not  authorized  to  handle  the  exception,  "  ) ; 

TEXT_IO.  FOTJZNE  (  Audit jrtailJText_File,  "  ",  & 

Exception_Name  &  "  raised  by  "  & 

Except! on_Raiser_Record.  Name  ) ; 

end  if; 


end  Iog_Exception_in_AuditJTrail; 


begin  —  Audit_Trail_Marager_Package  initialization 

Mandatory_Access_Control_Types_Package.  —  ^ee  3  -  3.1.3 

Others_String (  1  ..  6  )  :=  "others"; 

end  Audit JTrail_Manager_Package  ; 
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This  appendix  contains  an  abstract  for  each  of  three  documents  referenced  by  this 
report  concerning  the  LOCK  hardware  technology.  Where  available,  the  abstract 
was  taken  directly  from  the  referenced  document;  in  other  instances,  an  abstract 
was  either  written  for  a  document  or  the  existing  abstract  was  expanded. 
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SECURE  COMPUTING:  THE  SECURE  ADA  TARGET  APFROACH 


The  paper  proposes  to  secure  cccputing  with  a  small  trustworthy  hardware 
subsystem  of  a  ocnputer  that  is  not  subject  to  the  potential  penetrations 
inherent  in  software.  This  hardware  subsystem  "enforces  strict  rules  that 
protect  data  from  hostile  users.  The  subsystem  can  be  proved  trustworthy  in  a 
more  rigorous  sense  than  can  earlier  mechanisms."  This  subsystem  functions  as 
the  reference-monitor  mechanism,  or  security  kernel.  Overall,  this  subsystem 
"consists  of  three  state  spaces,  or  collections  of  three  state  spaces,  or 
collections  of  stored  information.  The  state  spaces  are  called  the  value  state, 
the  protection  state  and  the  underlying  abstractions.  The  value  state  consists 
of  all  objects  that  can  possibly  be  made  visible  to  subjects;  it  is  therefore 
outside  the  reference  monitor.  The  protection  state  and  the  underlying 
abstractions  are  the  information  that  the  reference  monitor  keeps  internal  to 
itself  and  uses  in  making  access  decisions.  At  this  level  the  protection  state 
is  represented  as  a  matrix  and  the  underlying  abstractions  are  represented  as 
tables.  The  paper  introduces  "the  concept  of  an  operation  invoked  by  a  subject 
and  performed  by  the  reference  monitor.  This  operation  consults  the  underlying 
abstractions  and  updates  the  protection  state  accordingly.  The  paper  further 
details  the  design  and  operation  of  this  hardware  reference  monitor  as  applied  to 
creating  a  tamper  resistant  Ada  target. 
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LOCKING  COMPUTERS  SECURELY 


Progress  has  been  slow  over  the  last  15  years  in  the  relatively  new  field  of 
computer  security.  Every  initiative  started  from  scratch  to  develop  a  S'  are 
computer.  First  prototypes,  built  in  software,  were  slow  and  difficult  to  use. 
LOCK  is  a  technology  research  and  development  project  to  build  a  hardware-based 
Reference  Monitor  module.  This  module  will  be  generic  and  thus  reusable  on  many 
different  computers.  Full  advantage  will  be  taken  of  inexpensive  generic 
cryptographic  modules  currently  in  development. 


D-5 


APPENDIX  D 

Abstracts  of  Three  Frequently  Referenced  Documents 


IDCiyix:  On  Implementing  Unix  on  the  LOCK  TCB 

In  the  LOCK/ix  version,  the  Logical  Coprocessing  Kernel  (LOCK)  is  a  Trusted 
Carputing  Base  (TCB)  that  is  designed  to  meet  and  exceed  the  requirements  for  a 
Class  A1  secure  system.  This  paper  describes  the  results  of  a  study  that 
determined  hew  to  port  the  Unix  System  V  Operating  System  to  the  IOCK  TCB,  while 
maintaining  maximum  compatibility  with  the  System  V  Interface  Definition  (SVID) 
[SVID86] . 
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